bpo-6721: Sanitize logging locks while forking by gpshead · Pull Request #4071 · python/cpython

Now it fails on the previous code and is fixed by the logging changes.
The test now uses a thread to hold the locks during the fork in a
synchronized manner.

Due to mixing of fork and a thread there is potential for deadlock
in the child process.  buildbots and time will tell if this actually
manifests itself in this test or not.  :/

bpo-6721: When os.fork() was called while another thread holds a logging lock, the child process may deadlock when it tries to log.  This fixes that by acquiring all logging locks before fork and releasing them afterwards.

A regression test that fails before this change is included.

Within the new unittest itself: There is a small _potential_ due to mixing of fork and a thread in the child process if the parent's thread happened to hold a non-reentrant library call lock (malloc?) when the os.fork() happens.  buildbots and time will tell if this actually manifests itself in this test or not.  :/  A functionality test that avoids that would be a challenge.

An alternate test that isn't trying to produce the deadlock itself but just checking that the release and acquire calls are made would be the next best alternative if so.
(cherry picked from commit 1900384)

Co-authored-by: Gregory P. Smith <greg@krypto.org> [Google]