Message139245
> 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 :-/ |
|
Date |
User |
Action |
Args |
2011-06-27 08:30:11 | pitrou | set | recipients:
+ pitrou, gregory.p.smith, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, avian |
2011-06-27 08:30:10 | pitrou | link | issue6721 messages |
2011-06-27 08:30:10 | pitrou | create | |
|