Gregory P. Smith <g...@krypto.org> added the comment:
Now to back up: Why was this application using fork() in a threaded
application at all? That is a fundamental flaw. Should we be doing work to
support things that so far merely _happen_ to work on such broken designs?
Another alternative for the DebugHandler implementation in whatever code
implemented it is for it to de-register itself from the logging library's
private WeakSet of handler locks to acquire at fork time from its own
constructor. We don't have a public API for this so the workaround doing that
on 3.7.1 - 3.7.3 would look like:
def __init__(self, ...):
super().__init__(...)
if hasattr(logging, '_at_fork_acquire_release_weakset'):
logging._at_fork_acquire_release_weakset.discard(self)
This means it'd still have the bug the code already had on all prior to
versions of Python before this logging library "acquire the locks before fork"
fix went in: Namely if the forked child tries to log it could deadlock due to
forking while the inherited logging handler lock held.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36533>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
