Message339480
| 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:35 | gregory.p.smith | set | recipients:
+ gregory.p.smith, vstinner, ned.deily, cagney |
| 2019年04月05日 09:02:35 | gregory.p.smith | set | messageid: <1554454955.19.0.2889074277.issue36533@roundup.psfhosted.org> |
| 2019年04月05日 09:02:35 | gregory.p.smith | link | issue36533 messages |
| 2019年04月05日 09:02:35 | gregory.p.smith | create |
|