➜

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.

作者 Giovanni.Bajo
收信人 Giovanni.Bajo, bobbyi, gregory.p.smith, neologix, nirai, pitrou, sdaoden, vstinner
日期 2011-06-25.15:15:46
SpamBayes Score 2.1185892e-10
Marked as misclassified 否
Message-id <1309014947.24.0.941872043265.issue6721@psf.upfronthosting.co.za>
In-reply-to
内容
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).
历史
日期 用户 动作 参数
2011-06-25 15:15:47Giovanni.Bajo修改recipients: + Giovanni.Bajo, gregory.p.smith, pitrou, vstinner, nirai, bobbyi, neologix, sdaoden
2011-06-25 15:15:47Giovanni.Bajo修改messageid: <1309014947.24.0.941872043265.issue6721@psf.upfronthosting.co.za>
2011-06-25 15:15:46Giovanni.Bajo链接issue6721 messages
2011-06-25 15:15:46Giovanni.Bajo创建