Nick Coghlan added the comment: Itamar wrote up a post describing the GC variant of this problem in more detail: https://codewithoutrules.com/2017/08/16/concurrency-python/
In particular, he highlighted a particularly nasty action-at-a-distance variant of the deadlock where: 1. Someone registers a logging.handlers.QueueHandler instance with the logging system 2. One or more types in the application or libraries it uses call logging functions in a __del__ method or a weakref callback 3. A GC cycle triggers while a log message is already being processed and hence the thread already holds the queue's put() lock 4. Things deadlock because the put() operation isn't re-entrant As far as I can see, there's no application level way of resolving that short of "Only register logging.handlers.QueueHandler with a logger you completely control and hence can ensure is never used in a __del__ method or weakref callback", which doesn't feel like a reasonable restriction to place on the safe use of a standard library logging handler. ---------- nosy: +ncoghlan _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14976> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
