Comment 2 for bug 1265150

Revision history for this message
Preston Landers (planders) wrote :

The problem is in how the Python logging package acquires locks recursively when it already holds a lock. With the base class's threading lock this is already handled.

I've got a git fork which fixes the problem here:

https://github.com/Preston-Landers/ConcurrentLogHandler

Tested with Python 3.6.0b4 x64 on Windows 10.

The problem is that logging.Handler calls acquire() to emit the message and then calls flush(), which also calls acquire() while the lock is already held, and this causes a deadlock given the locking technique used.

The fix in cloghandler.py is to keep track of the number of recursive acquires() and only do the actual locking or releasing when the stack is size 1.