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 vstinner
Recipients amaury.forgeotdarc, gregory.p.smith, isandler, pitrou, stutzbach, vstinner
Date 2010-12-03.13:11:30
SpamBayes Score 4.5524917e-11
Marked as misclassified No
Message-id <1291381892.6.0.960127311745.issue10478@psf.upfronthosting.co.za>
In-reply-to
Content
This issue remembers me #3618 (opened 2 years ago): I proposed to use RLock instead of Lock, but RLock was implemented in Python and were too slow. Today, we have RLock implemented in C and it may be possible to use them. Would it solve this issue?

--

There are at least two deadlocks, both in _bufferedwriter_flush_unlocked():
 - call to _bufferedwriter_raw_write()
 - call to PyErr_CheckSignals()

> 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.

Oh, so release the lock around the calls to _bufferedwriter_raw_write() (aorund PyObject_CallMethodObjArgs() in _bufferedwriter_raw_write()) and PyErr_CheckSignals() is not a good idea? Or is it just complex because the buffer object have to be in a consistent state?

> (in a more sophisticated version, we could store pending writes 
> so that they get committed at the end of the currently 
> executing write)

If the pending write fails, who gets the error?
History
Date User Action Args
2010-12-03 13:11:32vstinnersetrecipients: + vstinner, gregory.p.smith, isandler, amaury.forgeotdarc, pitrou, stutzbach
2010-12-03 13:11:32vstinnersetmessageid: <1291381892.6.0.960127311745.issue10478@psf.upfronthosting.co.za>
2010-12-03 13:11:30vstinnerlinkissue10478 messages
2010-12-03 13:11:30vstinnercreate