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 <miwin...@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 _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
