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

[glyph at divmod.com]

On Sat, 31 Dec 2005 10:57:21 -0800 (PST), Brian Warner <warner at lothar.com> wrote:
>>> 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.