This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gdb
Recipients asksol, gdb, jnoller
Date 2010-07-15.14:17:47
SpamBayes Score 0.009337074
Marked as misclassified No
Message-id <1279203470.17.0.864527074777.issue9205@psf.upfronthosting.co.za>
In-reply-to
Content
>> Before I forget, looks like we also need to deal with the
>> result from a worker being un-unpickleable:
>This is what my patch in bug 9244 does...
Really?  I could be misremembering, but I believe you deal with the case of the result being unpickleable.  I.e. you deal with the put(result) failing, but not the get() in the result handler.  Does my sample program work with your patch applied?

> while state != TERMINATE:
>      result = get(timeout=1)
>      if all_processes_dead():
>          break;
Will this sort of approach work with the supervisor, which continually respawns workers?

> user-initiated interrupts, this is very important to recover from,
> think of some badly written library code suddenly raising SystemExit,
> this shouldn't terminate other jobs, and it's probably easy to 
> recover from, so why shouldn't it try?
To be clear, in this case I was thinking of KeyboardInterrupts.

I'll take a look at your patch in a bit.  From our differing use-cases, I do think it could make sense as a configuration option, but where it probably belongs is on the wait() call of ApplyResult.
History
Date User Action Args
2010-07-15 14:17:50gdbsetrecipients: + gdb, jnoller, asksol
2010-07-15 14:17:50gdbsetmessageid: <1279203470.17.0.864527074777.issue9205@psf.upfronthosting.co.za>
2010-07-15 14:17:48gdblinkissue9205 messages
2010-07-15 14:17:47gdbcreate