Message121951
Wow. The lock is precisely there so that the buffered object doesn't have to be MT-safe or reentrant. It doesn't seem reasonable to attempt to restore the file to a "stable" state in the middle of an inner routine.
Also, the outer TextIOWrapper (we're talking about sys.stdout here) is not designed to MT-safe at all and is probably in an inconsistent state itself.
I would rather detect that the lock is already taken by the current thread and raise a RuntimeError. I don't think it's a good idea to do buffered I/O in a signal handler. Unbuffered I/O probably works.
(in a more sophisticated version, we could store pending writes so that they get committed at the end of the currently executing write) |
|
Date |
User |
Action |
Args |
2010-11-21 16:15:39 | pitrou | set | recipients:
+ pitrou, isandler, amaury.forgeotdarc |
2010-11-21 16:15:39 | pitrou | set | messageid: <1290356139.25.0.866713147269.issue10478@psf.upfronthosting.co.za> |
2010-11-21 16:15:35 | pitrou | link | issue10478 messages |
2010-11-21 16:15:35 | pitrou | create | |
|