On 30/09/2010 04:45, exarkun@twistedmatrix.com wrote:
On 12:52 am, chris@simplistix.co.uk wrote:
Because I haven't found any permutation that doesn't result in the LoopingCall's calls to `loop` from stopping after the exception.
I would be more than ecstatic to be proved wrong ;-)
You keep saying the LoopingCall stops. It does not stop. It is waiting for a result.
What result is it waiting for and how do I pass that from the `loop` function in my first example when the exception is caught?
If you provide it with a result, it will proceed.
See above: how do I do that?
Glyph suggested a number of (hackfully) mechanisms you might use to provide it with a result.
Why do you say hackfully? I'm trying to build a scheduler that is resilient to failure in a scheduled task. Yes, of course I want to fix that failure, but I don't want a failure in one scheduled task to prevent any further scheduled tasks from being executed...
I suggested another way (fix the broken code, or at least supply enough information for someone else to fix it).
For all I know, it's already fixed in a newer version of Twisted (unfortunately, I can't move this project to a newer version of Twisted) but once I have a robust scheduler, I'll certainly do my best to report the underlying failure to you guys properly... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk