Fixed QueueListener in order to avoid random deadlocks.
Unable to add regression tests atm due to time constraints, will add it in a bit.
Regarding implementation, although it's nested, it does not cause performance issues whatsoever, and does not call task_done() in case of an exception (which is the right thing to do IMHO).
https://bugs.python.org/issue36813
Instead of attempting to acquire and release them all across fork
which was leading to deadlocks in some applications that had chained
their own handlers while holding multiple locks.
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.
A check has been added in Logger.isEnabledFor() to return False when the logger is disabled. This avoids unnecessary work being done when a disabled logger is used.
This used to be the case on Python 2. Commit
212b590e11 changed the implementation for Python
3, making the `log()` method of LogAdapter call `logger._log()` directly. This
makes nested log adapters not execute their ``process()`` method. This patch
fixes the issue.
Also, now proxying `name`, too, to make `repr()` work with nested log adapters.
New tests added.
Some of the proxied methods use internal Logger state which isn't proxied,
causing failures if an adapter is applied to another adapter.
This commit fixes the issue, adds a new test for the use case.
The ConfigSocketReceiver.serve_until_stopped() method from
logging.config.listen() now calls server_close() (of
socketserver.ThreadingTCPServer) rather than closing manually the
socket.
While this change has no effect yet, it will help to prevent dangling
threads once ThreadingTCPServer.server_close() will join spawned
threads (bpo-31233).
Vinay Sajip
Boris Feld
Bar Harel
Riccardo Magliocchetti
Gregory P. Smith
Serhiy Storchaka
Rémi Lapeyre
Manjusaka
Josh Snyder
BNMetrics
Cheryl Sabella
Xtreak
Dong-hee Na
Timo Furrer
sanjayp
Lovesh Harchandani
Łukasz Langa
Victor Stinner
Antoine Pitrou
Preston Landers
favll
Avram Lubkin
Xiang Zhang
Jon Dufresne
Коренберг Марк