This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Giovanni.Bajo, avian, bobbyi, gregory.p.smith, neologix, nirai, pitrou, sdaoden, vstinner
Date 2011-06-27.08:30:10
SpamBayes Score 2.3159252e-13
Marked as misclassified No
Message-id <20110627103005.2598947f@msiwind>
In-reply-to <1309014947.24.0.941872043265.issue6721@psf.upfronthosting.co.za>
Content
> 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 :-/
History
Date User Action Args
2011-06-27 08:30:11pitrousetrecipients: + pitrou, gregory.p.smith, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, avian
2011-06-27 08:30:10pitroulinkissue6721 messages
2011-06-27 08:30:10pitroucreate