[Twisted-Python] a possible solution for ticket 5562

[gelin yan]

On Sun, Oct 21, 2012 at 3:35 AM, Glyph <glyph at twistedmatrix.com> wrote:

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


Hi All

   Thanks for reply. According to MSDN (link here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683209(v=vs.85).aspx
)

"A pending operation is indicated when the function that started the
operation returns *FALSE*, and the
*GetLastError*<http://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx>
function
returns *ERROR_IO_PENDING*. When an I/O operation is pending, the function
that started the operation resets the *hEvent* member of the
*OVERLAPPED* structure
to the nonsignaled state. Then when the pending operation has been
completed, the system sets the event object to the signaled state."

  If we can know when event object is in the signaled state we definitely
can use a queue directly. Any idea?

Regards

gelin yan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-python/attachments/20121021/0f04b061/attachment-0001.htm