On Mon, Feb 21, 2005 at 08:47:57PM +0000, glyph@divmod.com wrote:
On Mon, 21 Feb 2005 18:46:18 +0100, Andrea Arcangeli
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:
From the client send a flood of lines, and from the server call
Using the echoserver/client as base should be good enough to test this. 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.