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.

Author pitrou
Recipients Giovanni.Bajo, avian, bobbyi, gregory.p.smith, jcea, lesha, neologix, nirai, pitrou, sbt, sdaoden, vstinner
Date 2012-01-23.21:58:31
SpamBayes Score 3.8865956e-06
Marked as misclassified No
Message-id <1327355786.3370.3.camel@localhost.localdomain>
In-reply-to <1327354151.46.0.144996455673.issue6721@psf.upfronthosting.co.za>
Content
> Is there any particular reason not to merge Charles-François's reinit_locks.diff?
> 
> Reinitialising all locks to unlocked after a fork seems the only sane option.

I agree with this. 
I haven't looked at the patch very closely. I think perhaps each lock
could have an optional callback for specific code to be run after
forking, but that may come in another patch.
(this would allow to make e.g. the C RLock fork-safe)
History
Date User Action Args
2012-01-23 21:58:32pitrousetrecipients: + pitrou, gregory.p.smith, jcea, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, sbt, avian, lesha
2012-01-23 21:58:31pitroulinkissue6721 messages
2012-01-23 21:58:31pitroucreate