[issue45021] Race condition in thread.py

Antoine Pitrou added the comment: As the multiprocessing doc says (https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods): """Note that safely forking a multithreaded process is problematic.""" The reproducer is trivially fixed by adding a call to

[issue45021] Race condition in thread.py

Change by Antoine Pitrou : -- versions: +Python 3.10, Python 3.11 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue45021] Race condition in thread.py

0x0L added the comment: In the last reproducing example, one can drop the .result() and just submit the task: we're not waiting on any result explicitly. It's the shutdown of the ProcessPoolExecutor that waits forever for the children to exit. Generally speaking it's probably a bad idea to

[issue45021] Race condition in thread.py

hai shi added the comment: Is it a defined behavior? I got this sentence from pep-3148: Deadlock can occur when the callable associated with a Future waits on the results of another Future. -- nosy: +shihai1991 ___ Python tracker

[issue45021] Race condition in thread.py

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45021] Race condition in thread.py

STINNER Victor added the comment: I don't understand anything about multiprocessing, nor its API, but some people seem to find it useful :-D I remove myself from the nosy list ;-) -- ___ Python tracker

[issue45021] Race condition in thread.py

Change by Raymond Hettinger : -- nosy: +davin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45021] Race condition in thread.py

nullptr added the comment: Simplifying the reproducing example a bit more: from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor from time import sleep def submit(pool): pool.submit(submit, pool) if __name__ == '__main__': pool = ThreadPoolExecutor(1)

[issue45021] Race condition in thread.py

nullptr added the comment: I don't think so: this issue would only arise when using fork on linux and not spawn (win/osx) like it seems your system is doing -- ___ Python tracker

[issue45021] Race condition in thread.py

Irit Katriel added the comment: I'm seeing this (intermittently) on main branch, could be related? iritkatriel@Irits-MBP cpython-1 % ./python.exe Lib/test/test_importlib/partial/pool_in_threads.py Traceback (most recent call last): Traceback (most recent call last): Traceback (most recent

[issue45021] Race condition in thread.py

Change by Irit Katriel : -- nosy: +pitrou, vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45021] Race condition in thread.py

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 1.0 -> 2.0 pull_requests: +26449 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28007 ___ Python tracker

[issue45021] Race condition in thread.py

nullptr added the comment: A more direct way to reproduce from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor from time import sleep def worker(): with ProcessPoolExecutor() as pool: r = list(pool.map(sleep, [0.01] * 8)) def submit(pool):

[issue45021] Race condition in thread.py

Change by nullptr : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45021] Race condition in thread.py

New submission from nullptr : The following code can sometimes hang up import random from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor from time import sleep def worker():