Opened 12 years ago

Closed 10 years ago

#1473 defect closed duplicate (duplicate)

iocpreactor ignores pauseProducing from inside dataReceived

Reported by: ghazel Owned by:
Priority: high Milestone:
Component: core Keywords: win32
Cc: PenguinOfDoom, ghazel Branch:
Author:

Description


Change History (3)

comment:1 Changed 12 years ago by ghazel

because of this code in iocpreactor\abstract.py

    def handle_connected_readDone(self, bytes):
        if self.reading:
            self.protocol.dataReceived(self.readbuf[:bytes])
            self.startReading()

any call to transport.pauseProducing() from within the dataReceived handler is 
ignored (reverted to unpaused by startReading())

Something like this fixes it:

    def handle_connected_readDone(self, bytes):
        if self.reading:
            self.protocol.dataReceived(self.readbuf[:bytes])
            # the user may have called pauseProducing()
            if not self.reading:
                return
            self.startReading()

Also, this code in iocpreactor\abstract.py is questionable:

    def startReading(self):
        ...
        while self.producerBuffer:
            item = self.producerBuffer.pop(0)
            self.protocol.dataReceived(item)
            if not self.reading:
                return

Since that causes dataReceived messages to be fired during a call to 
transport.resumeProducing(). That is problematic when the dataReceived handler 
can call pauseProducing():

for transport in transports:
    transport.resumeProducing()

Now the state is inconsistant - perhaps a dataReceived handler tried to 
pauseProducing on all the trasnports in the middle of that loop, and the rest 
of the loop went on unpausing them.

comment:2 Changed 10 years ago by PenguinOfDoom

Resolution: duplicate
Status: newclosed

New IOCP does not do this. See #1760

comment:3 Changed 7 years ago by <automation>

Owner: PenguinOfDoom deleted
Note: See TracTickets for help on using tickets.