[Twisted-Python] Timeouts for Deferreds?

[Christopher Armstrong]

On Thu, 2002-05-02 at 23:00, Andrew Bennetts wrote:
> I just thought of another feature I would find handy in Deferreds,
> although perhaps this feature belongs somewhere else...
> 
> Deferred.timeout(secs):
>     If I am uncalled for secs seconds after being armed, call my errback
>     automatically.
> 
> This way callers can control how long they will wait for a Deferred to
> do something.  Methods returns Deferreds could also set a reasonable
> default with .timeout that the caller can override by calling .timeout
> again.  A timeout of None would, of course, mean never timeout.

I think something like this is definitely needed, because any timeout
anyone does with Twisted will probably be done while waiting for a
Deferred to return. 

> I can see this as being useful in many ways.  The biggest problem with
> it is I'm not sure what should happen when you try to call a Deferred
> after it has timed out (e.g. your CGI script took 5 minutes, timed out
> and thus called errback, but did eventually finish).  I don't think
> calling callback/errback should raise an AlreadyCalledException, because
> the timeout may have been set by a client of a library that doesn't
> expect timeouts.  On the other hand, I don't like the idea of things
> failing silently.  The ideal situation is, of course, to make sure that
> the timeout event always cancels whatever it is that would later call
> callback/errback, but I don't like making it a requirement that this
> must happen (plus it probably means adding a "timeback" method, or
> something).

I think a 'timeout' callback method or somesuch might be a good way to
do it, that way you just leave it up to the developer what to do when
something finally does callback/errback after a timeout has happened.

> Perhaps a TimeoutDeferred subclass?  But then it's not generally useful
> anymore, unless a method explicitly returns TimeoutDeferred and not
> Deferred.  Still, encouraging people to use hard-coded arbitrary
> timeouts everywhere probably isn't a good idea either.

I don't think it really needs to be a separate class - we can just have
an 'addTimeBack' method on Deferreds that creates a Delayed (or
something?) on the Deferred with the appropriate stuff. That way the
regular case of not using a timeout on a Deferred won't have any
overhead.

> Thoughts, anyone?
> 
> (Actual implementation details left as an exercise for the reader...
> actually, I'm happy to do it if people want this).

I guess either a Delayed or a main.addTimeout (err, it's not called
'main.addTimeout' anymore with the new Reactor refactor, but I don't
know what it is)

-- 
                                Chris Armstrong
                         << radix at twistedmatrix.com >>
                http://twistedmatrix.com/users/carmstro.twistd/