Fix a regression in handling processes that fork #645
Merged
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.
We switched from
pthread_atfork
handlers toos.register_at_fork
onesin order to support Python 3.13, where a lock that our child fork
handler needs to acquire will not have been reinitialized in the child
process at the time when
pthread_atfork
handlers run but will bereinitialized by the time
os.register_at_fork
handlers run.Unfortunately, this means that if a process forks without calling the
before
handler registered withos.register_at_fork
(as happens whenusing the "spawn" start method for multiprocessing, the default on
macOS), then our hooks are unexpectedly still active from the time the
process forks until the time that it execs another process image.
We can work around this by using a mix of both
pthread_atfork
andos.register_at_fork
handlers: we suspend tracking ina
pthread_atfork
prepare handler, resume it in apthread_atfork
handler in the parent process, and (if
--follow-fork
mode is used) wereinitialize it in the child process from an
os.register_at_fork
childhandler, after the interpreter's locks have been reinitialized.
Closes: #642