Repository navigation
🐛 fix(win32): reclaim a soft lock from an exited holder - #874
Merged
gaborbernat merged 1 commit intoOct 28, 2026
Merged
Conversation
…eeps it open process_alive() read any successful OpenProcess as a live process, but an exited process stays openable while any handle to it is open, such as a parent's subprocess.Popen after wait() or multiprocessing.Process after join(). A soft lock left by a crashed holder was then never reclaimed on Windows while its parent kept that object, and acquire() with the default timeout=-1 waited forever. Wait on the handle with a zero timeout and treat the process as gone only once it is signaled. A failed wait still reads as alive.
gaborbernat
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Windows, a soft lock left behind by a crashed worker was never reclaimed while any other process still held a handle to that worker. The usual case is the supervisor that started it:
multiprocessing.Processkeeps the child's handle afterjoin()untilclose()or garbage collection, andsubprocess.Popenkeeps it afterwait(). A supervisor that kept its worker objects and then took the lock waited forever with the defaulttimeout=-1, while Linux and macOS reclaimed the same marker at once. 🪟 Such a lock is now reclaimed as soon as the holder has exited, whoever still references it.The owner probe opened the recorded PID with
OpenProcessand read any successful open as a live process, but an exited process stays openable for as long as a handle to it exists, and its creation time still matches the marker's start token. The probe now also waits on that handle with a zero timeout: a process object is signaled once the process terminates, so only that signaled state counts as gone, and a timed-out or failed wait still counts as alive. Windows does not reuse a PID while a handle to it is open, so the stricter verdict adds no recycling risk, and the lock keeps breaking a marker only on proof of death.