On Saturday, Jan 18, 2003, at 19:14 America/New_York, Glyph Lefkowitz wrote:

On Sat, 18 Jan 2003 14:43:00 -0500, Bob Ippolito wrote:

...

What bothers me most isn't that an exception is being raised, but that it is impossible to reasonably catch that exception unless you subclass or otherwise do some nasty modifications to the reactor, deferred, or whichever class causes the exception.

I believe that I expressed concerns when setTimeout was originally proposed, noting that only the system firing the callback can reasonably terminate whatever process is doing the callback.

The meaning of "cancel" is domain-dependant, so if we want a general way of doing this then we need a way to express cancellation in the code which expects to be calling the callback. I think that the system that calls the callback is usually the one that creates the Deferred, so perhaps we could have an optional argument to the constructor, cancelCallback.

I can't help but feel this is a really ugly corner case, which would be inconvenient to effectively force everyone who uses a Deferred to implement in order for setTimeout to be callable. However, I don't have any better ideas. My original plan here was to always put timeouts somewhere else besides a Deferred, and have the system that calls the deferred call an errback at that point (such as with the "timeout" argument to connectTCP).

Another interesting case: what if two people call setTimeout on the same Deferred? If it's not purely the creator's responsibility to set the timeout on a Deferred, then what do we do about conflicts between different points in the processing chain?

You definitely raise some more interesting points here that didn't occur to me, especially the multiple-listener case. I can think of two approaches that could facilitate this.. 1) Have the actual operations inherit from Deferred, and have them deal with setTimeout and cancellation on their own. 2) Make cancellation some kind of delegate process.. On cancellation request, if there are other listeners on that deferred it asks them all if they're ok with cancellation. If all of them say yes, it cancels. Otherwise the ones that said yes are sent an errback saying that it was cancelled and removed from list of callback/errbacks (so it seems to them as if it were cancelled) but the ones that said no will remain as they were and the operation will not be cancelled.