Author pitrou
Recipients amaury.forgeotdarc, isandler, pitrou
Date 2010-11-21.16:15:35
SpamBayes Score 2.0267e-08
Marked as misclassified No
Message-id <1290356139.25.0.866713147269.issue10478@psf.upfronthosting.co.za>
In-reply-to
Content
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)
History
Date User Action Args
2010-11-21 16:15:39pitrousetrecipients: + pitrou, isandler, amaury.forgeotdarc
2010-11-21 16:15:39pitrousetmessageid: <1290356139.25.0.866713147269.issue10478@psf.upfronthosting.co.za>
2010-11-21 16:15:35pitroulinkissue10478 messages
2010-11-21 16:15:35pitroucreate