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 Olivier.Grisel
Recipients Olivier.Grisel, lars, sbt
Date 2013-09-11.11:02:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Maybe it would be better to have separate contexts for each start method.  That way joblib could use the forkserver context without interfering with the rest of the user's program.

Yes in general it would be great if libraries could customize the multiprocessing default options without impacting any of the module singletons. That also include the ForkingPickler registry for custom: now it's a class attribute. It would be great to be able to scope custom reducers registration to a given multiprocessing.Pool or multiprocessing.Process instance.

Now how to implement that kind of isolation: it could either be done by adding new constructor parameters or new public methods to the Process and Pool classes to be able to customize their behavior while sticking to the OOP paradigm if possible or by using a context manager as you suggested.

I am not sure which option is best. Prototyping both is probably the best way to feel the tradeoffs.
Date User Action Args
2013-09-11 11:02:26Olivier.Griselsetrecipients: + Olivier.Grisel, sbt, lars
2013-09-11 11:02:26Olivier.Griselsetmessageid: <>
2013-09-11 11:02:26Olivier.Grisellinkissue18999 messages
2013-09-11 11:02:25Olivier.Griselcreate