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 dan.oreilly
Recipients andreasvc, bquinlan, dan.oreilly, giampaolo.rodola, josh.r, mark.dickinson, mdengler
Date 2014-07-23.15:34:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1406129701.34.0.475790870647.issue21423@psf.upfronthosting.co.za>
In-reply-to
Content
It seems like everyone agrees that this functionality is useful, so I'm reviving this in hopes of getting a patch pushed through. I've updated Andreas' patch so that it applies cleanly against the latest tree, and tweaked the handling of exceptions in initializer. Now, ProcessPoolExecutor will raise a BrokenPoolException should an initializer method fail, and ThreadPoolExecutor will raise a RunTimeError stating that the pool can't be used because an initializer failed.

I was hoping to use multiprocessing.Pool's handling of initializer exceptions as a guide for the right behavior here, but it actually does terrible job: an exception raised in the initializer is completely unhandled, and results in an endless loop of new processes being started up and immediately failing. But that's a separate bug report. :)

For now there are still unit tests for testing exceptions being raised in the initializer, but they're noisy; the traceback for each initializer exception gets printed to stdout. I'm not sure if that's undesirable behavior or not.

If the new behavior looks ok, the docs will need an update to.
History
Date User Action Args
2014-07-23 15:35:01dan.oreillysetrecipients: + dan.oreilly, bquinlan, mark.dickinson, giampaolo.rodola, mdengler, josh.r, andreasvc
2014-07-23 15:35:01dan.oreillysetmessageid: <1406129701.34.0.475790870647.issue21423@psf.upfronthosting.co.za>
2014-07-23 15:35:01dan.oreillylinkissue21423 messages
2014-07-23 15:35:00dan.oreillycreate