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 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 <>
> > 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().
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: <>
2012-05-30 14:04:45sbtlinkissue6721 messages
2012-05-30 14:04:45sbtcreate