On Sat, 31 Dec 2005 10:57:21 -0800 (PST), Brian Warner
Yes it does: order of method call.
Hmm. Does it? The interface documentation is pretty light on guarantees, and that's on purpose: what happens if the user does callLater(0), then sets the system clock back, then does callLater(0) again?
Ah. That's useful to know: I would prefer to use a non-threading-related call to achieve this eventual-send functionality. I'll add a TODO test to check that this promise is being met.
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. That's not to say that stabilizing ordering in the win32 reactor is necessarily bad; but I think we should be careful with specifying overly strict behaviors with respect to the exact ordering that the reactor applies to different invocations of events, whether they're time or network or whatever. There should be some wiggle-room so that faster/fairer approaches can be tried.