Antoine Pitrou <pit...@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 <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
