[issue10478] Ctrl-C locks up the interpreter
STINNER Victor
report at bugs.python.org
Fri Dec 3 14:11:32 CET 2010
STINNER Victor <victor.stinner at haypocalc.com> added the comment:
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?
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10478>
_______________________________________
More information about the Python-bugs-list
mailing list