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. -Brian