Author lesha
Recipients Giovanni.Bajo, avian, bobbyi, gregory.p.smith, lesha, neologix, nirai, pitrou, sbt, sdaoden, vstinner
Date 2012-01-13.11:02:10
SpamBayes Score 1.52683e-10
Marked as misclassified No
Message-id <1326452531.03.0.423724201086.issue6721@psf.upfronthosting.co.za>
In-reply-to
Content
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!
History
Date User Action Args
2012-01-13 11:02:11leshasetrecipients: + lesha, gregory.p.smith, pitrou, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, sbt, avian
2012-01-13 11:02:11leshasetmessageid: <1326452531.03.0.423724201086.issue6721@psf.upfronthosting.co.za>
2012-01-13 11:02:10leshalinkissue6721 messages
2012-01-13 11:02:10leshacreate