On Sat, Jan 18, 2003 at 11:26:38PM +1100, Andrew Bennetts wrote:
On Fri, Jan 17, 2003 at 07:04:01PM -0500, Bob Ippolito wrote:
I've noticed that there isn't really a good/standard way to do timeouts (without bad things happening) or cancel deferreds in Twisted [without subclassing everything you use, which isn't good in my book].
I've glanced at your code and log, but it's not immediately clear to me what the problem is...
Nevermind me, I shouldn't try to read code and post when I'm tired. Your problem (if I'm understanding correctly :), is that exceptions are raised by calling Deferred.callback, if that Deferred has timed out, or otherwise been "cancelled" (by having its errback called). I'm tempted to argue that this is a feature: the code attempting to fire the callback probably should know that the Deferred has already expired due to an error. The obvious problem with this is that alot of the time you don't care if the Deferred has already fired or not, and wrapping d.callback(x) in a try/except AlreadyCalledError is hardly convenient. So I'd still like at least the option for an exception to be raised, even if it's disabled by default. I can't shake the feeling that some apps will need to know that it succeeds... although I guess they could just register their own .errback if they really care? For that matter, perhaps another solution would be to mandate that a method creating a Deferred is responsible for configuring it with an errback that will cancel pending operations so that .callback won't be called. Ugh, that's a confusing sentence. What I'm trying to say is that similarly to how when FTP opens a port and waits for a connection, it must set an errback to close that port if the connection never comes (e.g. due to an error on the control connection), whatever "owns" the Deferred should also cancel whatever would call .callback if an error occured -- this is probably necessary in general, not just for timeouts and cancels. Interesting problem :) -Andrew.