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

Andrea Arcangeli andrea at cpushare.com
Mon Feb 21 10:39:07 EST 2005

On Mon, Feb 21, 2005 at 04:13:53PM +1100, Andrew Bennetts wrote:
> On Mon, Feb 21, 2005 at 05:50:16AM +0100, Andrea Arcangeli wrote:
> [...]
> > 
> > The example in the docs is like this:
> > 
> > -------------------------
> > class FingerProtocol(basic.LineReceiver):
> >     def lineReceived(self, user):
> >         self.factory.getUser(user
> >         ).addErrback(lambda _: "Internal error in server"
> >         ).addCallback(lambda m:
> >             (self.transport.write(m+"\r\n"),
> >              self.transport.loseConnection()))
> > [..]
> > we would have to fetch result from a remote Oracle? Or from the web?
> > -------------------------
> > 
> > But as far as I can tell the above also is broken and it won't wait for
> > the deferred to fire, so two of those queries could be invoked if the
> > client side is malicious and it sends two lines in one packet and that
> > could screwup the server. It'll work only as long as the clients aren't
> > malicious.
> I don't think it matters if the two lines arrive in the same packet or not;
> if the lines arrive before the getUser deferred fires, it will fire multiple
> queries, regardless of the exact packets involved.  In this case maybe a
> flag should be in the protocol after the first lineReceived event... any

Well, it will raise an exception in transport.write at the very least,
in theory unhandled exceptions shouldn't happen. But the reason I
suggested to fix it, it to get people get the right mindset, unless they
know what they're doing, they should always call
LineReceiver.pauseProducing before executing the getUser(user),
otherwise a _real_ app that copied the above code, may get wrong for
more than just an exception.

> I think the transport's pauseProducing call will do what you want, here.
> And resumeProducing when you're ready again.

Yes, if I were using a unbuffered input.

Thanks a lot for the help!

More information about the Twisted-Python mailing list