[Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

[Antoine Pitrou]

Le mardi 23 août 2011 à 22:07 +0200, Charles-François Natali a écrit :
> 2011/8/23 Antoine Pitrou <solipsis at pitrou.net>:
> > Well, I would consider the I/O locks the most glaring problem. Right
> > now, your program can freeze if you happen to do a fork() while e.g.
> > the stderr lock is taken by another thread (which is quite common when
> > debugging).
> 
> Indeed.
> To solve this, a similar mechanism could be used: after fork(), in the
> child process:
> - just reset each I/O lock (destroy/re-create the lock) if we can
> guarantee that the file object is in a consistent state (i.e. that all
> the invariants hold). That's the approach I used in my initial patch.

For I/O locks I think that would work.
There could also be a process-wide "fork lock" to serialize locks and
other operations, if we want 100% guaranteed consistency of I/O objects
across forks.

> - call a fileobject method which resets the I/O lock and sets the file
> object to a consistent state (in other word, an atfork handler)

I fear that the complication with atfork handlers is that you have to
manage their lifecycle as well (i.e., when an IO object is destroyed,
you have to unregister the handler).

Regards

Antoine.