> I was clearly wrong about a release being done in the child being the right thing to do (issue6643 proved that, the state held by a lock is not usable to another process on all platforms such that release even works).

Yeah, apparently OS-X is one of them, the reporter in #11148 is
experiencing segfaults under OS-X.

> Are you suggesting to use pthread_atfork to call pthread_mutex_init on all mutexes created by Python in the child after a fork?  I'll have to ponder that some more.  Given the mutexes are all useless post fork it does not strike me as a bad idea.

Yes, that's what I was thinking. Instead of scattering the
lock-reclaiming code all over the place, try to use a more standard
API specifically designed with that in mind.
Note the base issue is that we're authorizing things which are
forbidden : in a multi-threaded process, only sync-safe calls are
authorized between fork and exec.

2011/2/10 Gregory P. Smith <report@bugs.python.org>:
>
> Gregory P. Smith <greg@krypto.org> added the comment:
>
> Yeah, I'm trying to figure out what I was thinking then or if I was just plain wrong. :)
>
> I was clearly wrong about a release being done in the child being the right thing to do (issue6643 proved that, the state held by a lock is not usable to another process on all platforms such that release even works).
>
> Part of it looks like I wanted a way to detect it was happening as any lock that is held during a fork indicates a _potential_ bug (the lock wasn't registered anywhere to be released before the fork) but not everything needs to care about that.
>
> ----------
> versions: +Python 3.3
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue6721>
> _______________________________________
>