[issue6721] Locks in python standard library should be sanitized on fork
lesha
report at bugs.python.org
Fri Jan 13 12:02:11 CET 2012
lesha <pybug.20.lesha at xoxy.net> added the comment:
Just wanted to say that I spent something like 8 hours debugging a subprocess + threading + logging deadlock on a real production system.
I suspected one of my locks at first, but I couldn't find any. The post-fork code was very simple, and I didn't suspect that logging would be subject to the same issue.
The good news that I see a very clean solution for fixing this.
We can't free all locks across fork -- that is unsafe and mad, because the child might end up corrupting some shared (network) resource, for example/
However, extending RLock to provide ForkClearedRLock (this would be used by logging, i.e.) is quite straighforward.
The extended class would simply need to record the process ID, in which the lock was created, and the process ID, which is trying to acquire it. Done!
----------
nosy: +lesha
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________
More information about the Python-bugs-list
mailing list