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 Giovanni.Bajo
Recipients Giovanni.Bajo, bobbyi, gregory.p.smith, neologix, nirai, pitrou, sdaoden, vstinner
Date 2011-06-25.15:15:46
SpamBayes Score 2.1185892e-10
Marked as misclassified No
Message-id <1309014947.24.0.941872043265.issue6721@psf.upfronthosting.co.za>
In-reply-to
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.

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).
History
Date User Action Args
2011-06-25 15:15:47Giovanni.Bajosetrecipients: + Giovanni.Bajo, gregory.p.smith, pitrou, vstinner, nirai, bobbyi, neologix, sdaoden
2011-06-25 15:15:47Giovanni.Bajosetmessageid: <1309014947.24.0.941872043265.issue6721@psf.upfronthosting.co.za>
2011-06-25 15:15:46Giovanni.Bajolinkissue6721 messages
2011-06-25 15:15:46Giovanni.Bajocreate