[Twisted-Python] a possible solution for ticket 5562

[Glyph]

I'm top-posting just for consistency in this thread, but in the future please comment inline with trimming :).  It's easier to follow for future readers; if they find a post stand-alone in some web archive, the question will come before the answer.

Anyhow; Mike, you're definitely closer to the answer; a callLater is unnecessary, the callback should be called on demand.  But, given that a queue of write operations is just that - a queue - we don't need a Deferred for every write; the callback to the write operation can just pick up the next queued item.

-g

On Oct 20, 2012, at 9:07 AM, Mike Winter <miwinter at cisco.com> wrote:

> This looks like the kind of thing that could involve using Deferred as part of solution. Instead of callLater(0.8,doWrite), design the mechanism to wire up event-source to fire the deferred and make doWrite be the callback.
> 
> On Oct 20, 2012, at 8:29:10AM, gelin yan wrote:
> 
>> Hi All
>> 
>>  A few months ago, I reported a bug about IOCP. Last night I spent several hours on its implementation and finally found out a possible solution for that.
>> 
>>  when sending some small chunks data continuously, the buffer will pile them up and send to IOCP; however there is a SEND_LIMIT (128K) that means only 128K will be handled. Now the problem is when we try to trigger the next writing, IOCP will raise ERROR_IO_PENDING immediately and then connection Lost.
>> 
>>  So I got a idea: if the size of data is larger than SEND_LIMIT, we can wait a little bit time for the next writing instead of do it immediately. 
>> 
>> in twisted\internet\iocpreactor\abstract.py there is a method
>> 
>> def _cbWrite(self, rc, bytes, evt):
>>        if self._handleWrite(rc, bytes, evt):
>>            self.doWrite()
>> 
>> now I modified a bit,
>> 
>> def _cbWrite(self, rc, bytes, evt):
>>        if self._handleWrite(rc, bytes, evt):
>>            if len(evt.buff) < self.SEND_LIMIT:
>>                self.doWrite()
>>            else:
>>                self.reactor.callLater(0.8,self.doWrite)
>> 
>> 
>> 
>> 0.8 is a silly trial but I have no idea what is the right number for this place. After this modification, previous problematic scripts can pass.
>> 
>> Maybe the better solution is to find a way to poll the complete port status when read/write will be recovered from IO PENDING. Simply wait a little is risky.
>> 
>> Regards