Richard Oudkerk <shibt...@gmail.com> added the comment: > > 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(). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6721> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
