➜
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 2017-07-20 14:58 by mickp, last changed 2022-04-11 14:58 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| alive.py | mickp, 2017-07-20 14:58 | |||
| Messages (3) | |||
|---|---|---|---|
| msg298724 - (view) | Author: Mick Phillips (mickp) | Date: 2017-07-20 14:58 | |
multiprocessing.Process.is_alive() returns True for processes that have been killed. See attached for example. Workaround: also test against psutils.pid_exists. |
|||
| msg298736 - (view) | Author: Gareth Rees (gdr@garethrees.org) *  |
Date: 2017-07-20 17:13 | |
This is a race condition — when os.kill returns, that means that the signal has been delivered, but it does not mean that the subprocess has exited yet. You can see this by inserting a sleep after the kill and before the liveness check:
print(proc.is_alive())
os.kill(proc.pid, signal.SIGTERM)
time.sleep(1)
print(proc.is_alive())
This (probably) gives the process time to exit. (Presumably the psutil.pid_exists() call has a similar effect.) Of course, waiting for 1 second (or any amount of time) might not be enough. The right thing to do is to join the process. Then when the join exits you know it died.
|
|||
| msg298745 - (view) | Author: Mick Phillips (mickp) | Date: 2017-07-20 19:13 | |
Yep - apologies, my mistake. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:58:49 | admin | set | github: 75159 |
| 2017-07-20 19:13:32 | mickp | set | status: open -> closed resolution: not a bug messages: + msg298745 stage: resolved |
| 2017-07-20 17:13:20 | gdr@garethrees.org | set | nosy:
+ gdr@garethrees.org messages: + msg298736 |
| 2017-07-20 14:58:52 | mickp | create | |