[issue6721] Locks in python standard library should be sanitized on fork

[Antoine Pitrou]

Antoine Pitrou <pitrou at free.fr> added the comment:

> If there's agreement that the general problem is unsolvable (so fork and
> threads just don't get along with each other), what we could attempt is
> trying to limit the side effects in the standard library, so that fewest
> users as possible are affected by this problem.

Actually, I think Charles-François' suggested approach is a good one.

> For instance, having deadlocks just because of print statements sounds
> like a bad QoI that we could attempt to improve. Is there a reason while
> BufferedIO needs to hold its internal data-structure lock (used to make
> it thread-safe) while it's doing I/O and releasing the GIL? I would think
> that it's feasible to patch it so that its internal lock is only used to
> synchronize accesses to the internal data structures, but it is never
> held while I/O is performed (and thus the GIL is released -- at which
> point, if another threads forks, the problem appears).

Not really. Whether you update the internal structures depends on the
result of the I/O (so that e.g. two threads don't flush the same buffer
simultaneously).

Also, finer-grained locking is always a risky endeavour and we already have
a couple of bugs to fix in the current buffered I/O implementation :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________