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.
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.
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/ ConcurrentLogHa ndler
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.