[Twisted-Python] how to stop dataReceived while waiting a deferred to fire?

[Andrea Arcangeli]

On Mon, Feb 21, 2005 at 08:47:57PM +0000, glyph at divmod.com wrote:
> On Mon, 21 Feb 2005 18:46:18 +0100, Andrea Arcangeli <andrea at cpushare.com> wrote:
> 
> > Ok here we go, I even found a severe bug in the linereceiver code and I
> > fixed it as well. The bug in linereceiver happens like this:
> 
> Any chance that you could include some unit tests for the behavior
> you're expecting?  I think it might need to be fixed a different way.
> For example:

Using the echoserver/client as base should be good enough to test this.
>From the client send a flood of lines, and from the server call
pauseProducing() after the first line has been received. Then verify the
server doesn't receive the other lines and that they sit in the tcp recv
queue.

> > -        while len(self.recvd) > 1:
> > +        while len(self.recvd) > 1 and not self.paused:
> 
> This seems like it could lead to some unpleasantly large (i.e.
> quadratic-time concatenation) buffers strings being left around if you
> pause one of these receivers and then forget to unpause it, or even

Won't the data be freed along with the protocol when the connection is
closed? The protocol should go away when the connection is closed.

> just if your peer happens to be sending data very rapidly.

The high bound of in flight receive data for each int32 protocol is set
to 99999 (protocol.MAX_LENGTH), and the reactor will read with a limited
buffer too. So I don't see any problem as long as
transport.pauseProducing() does what's expected to do (i.e. to stop
polling the socket and to stop receiving data from the wire).

Anyway if there's still a problem, let's ignore my problem, and let's
only focus on the LineReceiver implementation that is already in current
twisted. As long as LineReceiver works my patch is going to be fine.

There was a reentrancy bug in LineReceiver but I already fixed it.