Browse Source
bpo-6721: Hold logging locks across fork() (GH-4071)
bpo-6721: Hold logging locks across fork() (GH-4071)
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.pull/9297/head
committed by
GitHub
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 119 additions and 0 deletions
-
50Lib/logging/__init__.py
-
67Lib/test/test_logging.py
-
2Misc/NEWS.d/next/Library/2018-09-13-10-09-19.bpo-6721.ZUL_F3.rst
@ -0,0 +1,2 @@ |
|||
Acquire the logging module's commonly used internal locks while fork()ing to |
|||
avoid deadlocks in the child process. |
|||
Write
Preview
Loading…
Cancel
Save
Reference in new issue