Author gregory.p.smith
Recipients cagney, gregory.p.smith, ned.deily, vstinner
Date 2019-04-05.08:15:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1554452151.49.0.211568667786.issue36533@roundup.psfhosted.org>
In-reply-to
Content
I'm spawning a dicussion buried in the way too long thread of https://bugs.python.org/issue6721 over here into its own specific issue to treat as a 3.7 release blocker for a rollback or repair decision before 3.7.4.

https://github.com/python/cpython/commit/3b699932e5ac3e76031bbb6d700fbea07492641d

I believe that was released in 3.7.1 is leading to a behavior regression for an application (the Fedora installer's libreswan kvmrunner?).  Full details can be found in the messages of the other issue starting with:
  https://bugs.python.org/issue6721#msg329474

TL;DR - logging.Handler instances each have their own threading.Rlock. 
libreswan implements at least one logging.Handler subclass.  That subclass's custom emit() implementation directly calls potentially many other sub-handlers emit() methods.  Some of those emit() methods (such as logging.StreamHandler) call flush() which acquires the handler's lock.

So they've got a dependency between these two locks, the first's must be acquired before the second.

But the logging module APIs have no concept of sub-handlers and lock ordering.

I see many flaws with the libreswan code's design (I'm already ignoring the futility of threading + fork) but this still caused a behavior regression in the stable 3.7 release.

(more comments coming as followups to avoid a wall of text with too many topics)
History
Date User Action Args
2019-04-05 08:15:51gregory.p.smithsetrecipients: + gregory.p.smith, vstinner, ned.deily, cagney
2019-04-05 08:15:51gregory.p.smithsetmessageid: <1554452151.49.0.211568667786.issue36533@roundup.psfhosted.org>
2019-04-05 08:15:51gregory.p.smithlinkissue36533 messages
2019-04-05 08:15:51gregory.p.smithcreate