[issue31310] semaphore tracker isn't protected against crashes

Serhiy Storchaka added the comment: Sorry, that bug was actually introduced in issue33613. -- stage: needs patch -> resolved status: open -> closed ___ Python tracker ___

[issue31310] semaphore tracker isn't protected against crashes

Change by Pablo Galindo Salgado : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31310] semaphore tracker isn't protected against crashes

Serhiy Storchaka added the comment: Tests are failed when ran with -Werror. $ ./python -We -m test -vuall test_multiprocessing_fork test_multiprocessing_forkserver test_multiprocessing_spawn ... == ERROR:

[issue31310] semaphore tracker isn't protected against crashes

Thomas Moreau added the comment: > Is it an optimization problem, or does it risk leaking semaphores? I do not think it risks leaking semaphores as the clean-up is performed by the process which created the Semaphore. So I would say it is more an optimization

[issue31310] semaphore tracker isn't protected against crashes

Antoine Pitrou added the comment: > Thus, as the _pid argument is None in the new process, it launches a new > tracker if it needs to create a new Semaphore I see. Is it an optimization problem, or does it risk leaking semaphores? The problem is if a semaphore shared with

[issue31310] semaphore tracker isn't protected against crashes

Thomas Moreau added the comment: For new processes created with spawn or forkserver, only the semaphore_tracker._fd is send and shared to the child. Thus, as the _pid argument is None in the new process, it launches a new tracker if it needs to create a new

[issue31310] semaphore tracker isn't protected against crashes

Antoine Pitrou added the comment: > With this fix, the semaphore_tracker is not shared with the children anymore > and each process launches its own tracker. That's only if the semaphore tracker process crashes, right? -- ___

[issue31310] semaphore tracker isn't protected against crashes

Thomas Moreau added the comment: With this fix, the semaphore_tracker is not shared with the children anymore and each process launches its own tracker. I opened a PR to try to fix it. Let me know if I should open a new ticket. -- nosy: +tomMoral

[issue31310] semaphore tracker isn't protected against crashes

Change by Thomas Moreau : -- pull_requests: +5025 ___ Python tracker ___ ___

[issue31310] semaphore tracker isn't protected against crashes

Change by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue31310] semaphore tracker isn't protected against crashes

Antoine Pitrou added the comment: New changeset b5f09acf0a0219cec32b7eba3acdcb573fc74ab5 by Antoine Pitrou in branch '3.6': [3.6] bpo-31310: multiprocessing's semaphore tracker should be launched again if crashed (GH-3247) (#4254)

[issue31310] semaphore tracker isn't protected against crashes

Change by Antoine Pitrou : -- keywords: +patch pull_requests: +4216 ___ Python tracker ___

[issue31310] semaphore tracker isn't protected against crashes

Antoine Pitrou added the comment: New changeset cbe1756e3ecefc0e24a5d0a4b8663db9b6d0cc52 by Antoine Pitrou in branch 'master': bpo-31310: multiprocessing's semaphore tracker should be launched again if crashed (#3247)

[issue31310] semaphore tracker isn't protected against crashes

Changes by Antoine Pitrou : -- stage: needs patch -> patch review ___ Python tracker ___ ___

[issue31310] semaphore tracker isn't protected against crashes

Changes by Antoine Pitrou : -- pull_requests: +3292 ___ Python tracker ___ ___

[issue31310] semaphore tracker isn't protected against crashes

New submission from Antoine Pitrou: Similar to bpo-31308, but pertaining to multiprocessing's semaphore tracker process. -- components: Library (Lib) messages: 301029 nosy: davin, pitrou priority: normal severity: normal stage: needs patch status: open title: semaphore tracker isn't