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 ncoghlan
Recipients ncoghlan
Date 2013-02-06.02:08:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
In-reply-to
Content
The multiprocessing module currently provides the "multiprocessing.dummy.ThreadPool" API that exposes the same API as the public multiprocessing.Pool, but is implemented with threads rather than processes. (This is sort of documented - it's existence is implied by the documentation of multiprocessing.dummy, but it doesn't spell out "hey, stdlib ThreadPool implementation!".

Given that this feature is likely useful to many people for parallelising IO bound tasks without migrating to the concurrent.futures API (or where that API doesn't quite fit the use case), it makes sense to make it a more clearly documented feature under a less surprising name.

I haven't looked at the implementation, so I'm not sure how easy it will be to migrate it to a different module, but threading seems like a logical choice given the multiprocessing.ThreadPool vs threading.ThreadPool parallel.

(Honestly, I'd be happier if we moved queue.Queue to threading as well. Having a threading specific data type as a top level module in its own right just makes it harder for people to find for no real reason other than a historical accident)

Alternatively, we could add a "concurrent.pool" module which was little more than:

from multiprocessing import Pool as ProcessPool
from multiprocessing.dummy import ThreadPool
History
Date User Action Args
2013-02-06 02:08:05ncoghlansetrecipients: + ncoghlan
2013-02-06 02:08:05ncoghlansetmessageid: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
2013-02-06 02:08:05ncoghlanlinkissue17140 messages
2013-02-06 02:08:04ncoghlancreate