This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

作者 lesha
收信人 Giovanni.Bajo, avian, bobbyi, gregory.p.smith, lesha, neologix, nirai, pitrou, sbt, sdaoden, vstinner
日期 2012-01-13.11:02:10
SpamBayes Score 1.5268292e-10
Marked as misclassified
Message-id <1326452531.03.0.423724201086.issue6721@psf.upfronthosting.co.za>
In-reply-to
内容
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!
历史
日期 用户 动作 参数
2012-01-13 11:02:11lesha修改recipients: + lesha, gregory.p.smith, pitrou, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, sbt, avian
2012-01-13 11:02:11lesha修改messageid: <1326452531.03.0.423724201086.issue6721@psf.upfronthosting.co.za>
2012-01-13 11:02:10lesha链接issue6721 messages
2012-01-13 11:02:10lesha创建