Message161953
> > 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:46 | sbt | set | recipients:
+ sbt, gregory.p.smith, vinay.sajip, jcea, pitrou, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, avian, lesha |
2012-05-30 14:04:46 | sbt | set | messageid: <1338386686.28.0.661690464175.issue6721@psf.upfronthosting.co.za> |
2012-05-30 14:04:45 | sbt | link | issue6721 messages |
2012-05-30 14:04:45 | sbt | create | |
|