[issue17127] multiprocessing.dummy.Pool does not accept maxtasksperchild argument

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17127] multiprocessing.dummy.Pool does not accept maxtasksperchild argument

Mark Lawrence added the comment: I've confirmed that the behaviour is identical in 3.4.1 on Windows. -- nosy: +BreamoreBoy, jnoller, sbt versions: +Python 3.4, Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org

[issue17127] multiprocessing.dummy.Pool does not accept maxtasksperchild argument

Josh Rosenberg added the comment: Note: To my knowledge there is little or no benefit to using maxtasksperchild when the implementation is using threads. Cleaning up worker processes intermittently will guarantee that memory, handles, etc., are returned to the OS. But memory and handles

[issue17127] multiprocessing.dummy.Pool does not accept maxtasksperchild argument

Josh Rosenberg added the comment: Actually, now that I think about, most thread local stuff wouldn't be freed automatically either, since it's still allocated from a common pool of memory, and interleaved allocations would still prevent memory blocks from being returned to the OS. As far as

[issue17127] multiprocessing.dummy.Pool does not accept maxtasksperchild argument

New submission from Noah Yetter: Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. The docs claim that multiprocessing.dummy replicates the API of multiprocessing but is no more than a wrapper