Author sbt
Recipients Giovanni.Bajo, avian, bobbyi, gregory.p.smith, jcea, lesha, neologix, nirai, pitrou, sbt, sdaoden, vinay.sajip, vstinner
Date 2012-05-30.14:04:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1338386686.28.0.661690464175.issue6721@psf.upfronthosting.co.za>
In-reply-to
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)

An alternative way of handling RLock.acquire() would be to always start by trying a non-blocking acquire while holding the GIL: if this succeeds and self->rlock_count != 0 then we can assume that the lock was cleared by PyThread_ReinitLocks().
History
Date User Action Args
2012-05-30 14:04:46sbtsetrecipients: + sbt, gregory.p.smith, vinay.sajip, jcea, pitrou, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, avian, lesha
2012-05-30 14:04:46sbtsetmessageid: <1338386686.28.0.661690464175.issue6721@psf.upfronthosting.co.za>
2012-05-30 14:04:45sbtlinkissue6721 messages
2012-05-30 14:04:45sbtcreate