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.
Created on 2010年11月05日 22:22 by Jimbofbx, last changed 2022年04月11日 14:57 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| pool_lifetime_close-1.diff | neologix, 2011年10月21日 19:46 | review | ||
| Messages (8) | |||
|---|---|---|---|
| msg120547 - (view) | Author: James Hutchison (Jimbofbx) | Date: 2010年11月05日 22:22 | |
v.3.2a3
If the maxtasksperchild argument is used, the program will just hang after whatever that value is rather than working as expected. Tested in Windows XP 32-bit
test code:
import multiprocessing
def f(x):
return 0;
if __name__ == '__main__':
pool = multiprocessing.Pool(processes=2,maxtasksperchild=1);
results = list();
for i in range(10):
results.append(pool.apply_async(f, (i)));
pool.close();
pool.join();
for r in results:
print(r);
print("Done");
|
|||
| msg133003 - (view) | Author: Jesse Keating (jkeating) | Date: 2011年04月05日 05:12 | |
I can duplicate this using python-2.7-8.fc14.1 on Fedora 14, and using map_async with the pool. |
|||
| msg133648 - (view) | Author: Charles-François Natali (neologix) * (Python committer) | Date: 2011年04月13日 08:19 | |
This problem arises because the pool's close method is called before all the tasks have completed. Putting a sleep(1) before pool.close() won't exhibit this lockup. The root cause is that close makes the workers handler thread exit: since the maxtasksperchild argument is used, workers exit when they've processed their max number of tasks. But since the workers handler thread exited, it doesn't maintain the pool of workers anymore, and thus the remaining tasks are not treated anymore, and the task handler thread waits indefinitely (since it waits until the cache is empty). The solution is to prevent the worker handler thread from exiting until the cache has been drained (unless the pool is terminated in which case it must exit right away). Attached is a patch and relevant test. Note: I noticed that there are some thread-unsafe operations (the cache that can be modified from different threads, and thread states are modified also from different threads). While this isn't an issue with the current cPython implementation (GIL), I wonder if this should be fixed. |
|||
| msg133667 - (view) | Author: Jesse Noller (jnoller) * (Python committer) | Date: 2011年04月13日 13:53 | |
> Note: I noticed that there are some thread-unsafe operations (the cache that can be modified from different threads, and thread states are modified also from different threads). While this isn't an issue with the current cPython implementation (GIL), I wonder if this should be fixed. > Yes. We should fix those. |
|||
| msg146119 - (view) | Author: Charles-François Natali (neologix) * (Python committer) | Date: 2011年10月21日 19:46 | |
Here's an updated patch. I'll open a separate issue for the thread-safety. |
|||
| msg146268 - (view) | Author: Antoine Pitrou (pitrou) * (Python committer) | Date: 2011年10月23日 23:09 | |
The patch looks good to me, thanks. |
|||
| msg146308 - (view) | Author: Roundup Robot (python-dev) (Python triager) | Date: 2011年10月24日 16:45 | |
New changeset 3465a9b2d25c by Charles-François Natali in branch '2.7': Issue #10332: multiprocessing: fix a race condition when a Pool is closed http://hg.python.org/cpython/rev/3465a9b2d25c New changeset 52c98a729a71 by Charles-François Natali in branch '3.2': Issue #10332: multiprocessing: fix a race condition when a Pool is closed http://hg.python.org/cpython/rev/52c98a729a71 New changeset c2cdabc44665 by Charles-François Natali in branch 'default': Issue #10332: multiprocessing: fix a race condition when a Pool is closed http://hg.python.org/cpython/rev/c2cdabc44665 |
|||
| msg146313 - (view) | Author: Charles-François Natali (neologix) * (Python committer) | Date: 2011年10月24日 18:06 | |
James, thanks for the report! |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:08 | admin | set | github: 54541 |
| 2012年03月26日 13:15:21 | neologix | link | issue14404 superseder |
| 2011年10月24日 18:06:42 | neologix | set | status: open -> closed resolution: fixed messages: + msg146313 stage: patch review -> resolved |
| 2011年10月24日 16:45:29 | python-dev | set | nosy:
+ python-dev messages: + msg146308 |
| 2011年10月23日 23:09:35 | pitrou | set | messages:
+ msg146268 versions: + Python 3.3, - Python 3.1 |
| 2011年10月21日 19:47:20 | neologix | set | files: - pool_lifetime_close.diff |
| 2011年10月21日 19:46:57 | neologix | set | files:
+ pool_lifetime_close-1.diff nosy: + pitrou messages: + msg146119 keywords: + needs review stage: patch review |
| 2011年04月13日 13:53:23 | jnoller | set | messages: + msg133667 |
| 2011年04月13日 08:19:50 | neologix | set | files:
+ pool_lifetime_close.diff nosy: + neologix messages: + msg133648 keywords: + patch |
| 2011年04月05日 05:12:09 | jkeating | set | nosy:
+ jkeating messages: + msg133003 |
| 2010年11月05日 22:24:31 | pitrou | set | nosy:
+ jnoller, asksol type: behavior versions: + Python 3.1, Python 2.7 |
| 2010年11月05日 22:22:28 | Jimbofbx | create | |