This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients cagney, gregory.p.smith, ned.deily, vstinner
Date 2019-04-05.09:02:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1554454955.19.0.2889074277.issue36533@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2019-04-05 09:02:35gregory.p.smithsetrecipients: + gregory.p.smith, vstinner, ned.deily, cagney
2019-04-05 09:02:35gregory.p.smithsetmessageid: <1554454955.19.0.2889074277.issue36533@roundup.psfhosted.org>
2019-04-05 09:02:35gregory.p.smithlinkissue36533 messages
2019-04-05 09:02:35gregory.p.smithcreate