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:09gregory.p.smithsetrecipients: + gregory.p.smith, vstinner, ned.deily, cagney
2019-04-05 08:23:09gregory.p.smithsetmessageid: <1554452589.95.0.0723849823313.issue36533@roundup.psfhosted.org>
2019-04-05 08:23:09gregory.p.smithlinkissue36533 messages
2019-04-05 08:23:09gregory.p.smithcreate