Re: [Twisted-Python] Deferred execution, timeouts, and unhandled exceptions
On Saturday, Jan 18, 2003, at 07:57 America/New_York, Andrew Bennetts wrote:
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...
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.
That's exactly what I am proposing! :) Look at the class "DoesHandleTimeoutsByItself" -- that's exactly what it does, register an errback to a method such that it can cancel what it's doing so that it never tries to do a callback or another errback. 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. -bob
On Sat, 18 Jan 2003 14:43:00 -0500, Bob Ippolito <bob@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? -- | <`'> | Glyph Lefkowitz: Travelling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |
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@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.
participants (2)
-
Bob Ippolito -
Glyph Lefkowitz