[Twisted-Python] Deferred execution, timeouts, and unhandled exceptions

[Bob Ippolito]

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 <bob at redivi.com> 
> 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.