[Twisted-Python] Re: r15451 - Fix test failures under windows by changing the eventual-send operation to

Brian Warner warner at lothar.com
Sat Dec 31 17:04:27 EST 2005

> I think that your eventual-send queue should probably be its own
> event-queuing API. If you have:
>  callLater(0, foo); callLater(0, bar)
> and you expect ordering between them, something like this is better:
>  callLater(0, lambda : foo(); bar())
> or perhaps
>  myRunQueue.put(foo); myRunQueue.put(bar); callLater(0, myRunQueue.activate)
> You get the idea.

The issue here is with multiple eventual-sends being called from other code.
Specifically, the context was an ITransport-providing Loopback class, used in
newpb unit tests, which needs to decouple transport.write() from the
resulting proto.dataReceived(). The write() calls are being made from all
over the place, with no good location to coordinate or batch them together.
Technically I could rig it so that transport.write() queues the data and then
oblige the writing Protocol to invoke transport.flush() (newpb has a place
for this to go, to support more datagram-oriented transports someday), but
then who's to say that whatever code invokes *that* won't want to run
multiple times in a brief period of time?

I heartily agree that callLater() is not the appropriate tool for this
purpose. A week ago I thought it might be, but at that point I didn't realize
that I need the ordering guarantee described above. The implementation of
callFromThread() happens to match both my needs and my expectations about
efficiency, but of course it isn't documented to provide either, plus this
eventual-send functionality should be completely unrelated to threads.


More information about the Twisted-Python mailing list