Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork34.3k
bpo-36668: FIX reuse semaphore tracker for child processes#5172
bpo-36668: FIX reuse semaphore tracker for child processes#5172pitrou merged 12 commits intopython:masterfrom
Conversation
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Co-Authored-By: tomMoral <thomas.moreau.2010@gmail.com>
tomMoral commentedApr 19, 2019
@pitrou This PR avoid spawning |
tomMoral commentedApr 19, 2019
@pitrou I think this PR is ready |
pitrou left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Looks mostly good to me. Just a single comment.
Uh oh!
There was an error while loading.Please reload this page.
pitrou left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
+1 from me
pitrou commentedApr 24, 2019
@tomMoral Can you force-push to trigger an AppVeyor build? |
tomMoral commentedApr 24, 2019
Done |
bedevere-bot commentedApr 24, 2019
@pitrou: Please replace |
pitrou commentedApr 24, 2019
Thanks@tomMoral . I don't think this needs to be backported to 3.7, do you concur? |
tomMoral commentedMay 7, 2019
@pitrou yes I agree this is not critical so it is not necessary to backport to 3.7. |
Uh oh!
There was an error while loading.Please reload this page.
The current implementation of the
semaphore_trackercreates a new process for each children.This PR intends to fix this behavior.
The easy fix would be to pass the
_pidto the children but the current mechanism to check if thesemaphore_trackeris alive relies onwaitpidwhich cannot be used in child processes (thesemaphore_trackeris only a sibling of these processes). The main issue is to have a reliable check that either:waitpid, I don't see an efficient mechanism.I took the approach of adding a
PROBEcommand in the semaphore tracker. When the pipe is closed, the send command fails and this means the semaphore tracker is down.https://bugs.python.org/issue36668