Charles-Francois Natali <neolo...@free.fr> added the comment: > 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 <rep...@bugs.python.org>: > > Gregory P. Smith <g...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue6721> > _______________________________________ > ---------- _______________________________________ 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
