lesha <pybug.20.le...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue6721> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
