Message339474
| Author |
gregory.p.smith |
| Recipients |
cagney, gregory.p.smith, ned.deily, vstinner |
| Date |
2019年04月05日.08:23:09 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1554452589.95.0.0723849823313.issue36533@roundup.psfhosted.org> |
| In-reply-to |
| Content |
That custom DebugHandler's emit() implementation that calls into one or more sub-handlers suggests that libreswan _might_ be able to fix it in the custom DebugHandler by implementing custom acquire() and release() methods... BUT that is a fundamentally flawed problem: It requires acquiring multiple locks in a single atomic operation OR guaranteeing that they will always be acquired in a single specific order.
Given the logging module's fork-time code maintains no order, even implementing a custom acquire() and release() method in your custom DebugHandler would not be sufficient as sub-handler locks could be acquired first during fork. also, that would be assuming your sub-handlers are not also used directly elsewhere within all possible coexisting logger configurations.
An implementable _gross workaround_ that libreswan or anything else in this boat could implement satisfying that constraint would be to force all potentially related handlers to share the same single RLock instance. :( |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2019年04月05日 08:23:09 | gregory.p.smith | set | recipients:
+ gregory.p.smith, vstinner, ned.deily, cagney |
| 2019年04月05日 08:23:09 | gregory.p.smith | set | messageid: <1554452589.95.0.0723849823313.issue36533@roundup.psfhosted.org> |
| 2019年04月05日 08:23:09 | gregory.p.smith | link | issue36533 messages |
| 2019年04月05日 08:23:09 | gregory.p.smith | create |
|