[issue3618] possible deadlock in IO library (Lib/io.py)

Benjamin Peterson added the comment: 2009/2/28 Antoine Pitrou : > > Antoine Pitrou added the comment: > > I don't know. The RLock is a lot slower than the normal non-recursive > variation, on the other hand I'm not sure we care about performance of > the Python version that much. Opinions welco

[issue3618] possible deadlock in IO library (Lib/io.py)

Antoine Pitrou added the comment: I don't know. The RLock is a lot slower than the normal non-recursive variation, on the other hand I'm not sure we care about performance of the Python version that much. Opinions welcome. ___ Python tracker

[issue3618] possible deadlock in IO library (Lib/io.py)

Benjamin Peterson added the comment: Yes, this is solved in the io-c branch. Antoine, do you think we should switch _pyio to use the RLock? -- nosy: +benjamin.peterson ___ Python tracker ___

[issue3618] possible deadlock in IO library (Lib/io.py)

STINNER Victor added the comment: The test (io_deadlock.patch) pass on the io-c branch \o/ ___ Python tracker ___ ___ Python-bugs-list mailing

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by Gabriel Genellina : -- nosy: +gagenellina ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue3618] possible deadlock in IO library (Lib/io.py)

STINNER Victor added the comment: I hope that this issue will be fixed by io-c (io library rewritten in C language). ___ Python tracker ___ __

[issue3618] possible deadlock in IO library (Lib/io.py)

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: (I have to add that the patch makes small reads about 60-80% slower) ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by Antoine Pitrou <[EMAIL PROTECTED]>: -- keywords: +needs review ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-lis

[issue3618] possible deadlock in IO library (Lib/io.py)

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Here is a patch. The RLock implementation is naive and as simple as possible. It doesn't solve Haypo's case, probably because the tracing func kicks in in the RLock code itself. I don't want to make a decision on this alone, so someone please

[issue3618] possible deadlock in IO library (Lib/io.py)

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: We might as well bite the bullet and include a short, minimalist RLock implementation in io.py (so as not to pull threading and all its dependencies at startup). The C version of RLock will wait for 3.1. __

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- priority: release blocker -> critical ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by Jesús Cea Avión <[EMAIL PROTECTED]>: -- nosy: +jcea ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing l

[issue3618] possible deadlock in IO library (Lib/io.py)

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Selon STINNER Victor <[EMAIL PROTECTED]>: > > So if we consider that RLock is fast enough (see my C version of RLokc > in #3001), we can use RLock instead of Lock to avoid this issue. Here > is a patch to use RLock and also including an unit t

[issue3618] possible deadlock in IO library (Lib/io.py)

STINNER Victor <[EMAIL PROTECTED]> added the comment: So if we consider that RLock is fast enough (see my C version of RLokc in #3001), we can use RLock instead of Lock to avoid this issue. Here is a patch to use RLock and also including an unit test of this issue. Added file: http://bugs.pyth

[issue3618] possible deadlock in IO library (Lib/io.py)

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: see the python-3000 thread I just started asking for opinions on this. I'd personally say this bug is a good reason to go ahead with #3001 for 3.0. ___ Python tracker <[EMAIL PROTECTED]>

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- nosy: +gregory.p.smith ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-li

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: high -> deferred blocker ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyt

[issue3618] possible deadlock in IO library (Lib/io.py)

STINNER Victor <[EMAIL PROTECTED]> added the comment: Ooops again, I uploaded my patch to the wrong issue! The new patch is now in the issue #3001. ___ Python tracker <[EMAIL PROTECTED]> _

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11174/rlock.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3618] possible deadlock in IO library (Lib/io.py)

STINNER Victor <[EMAIL PROTECTED]> added the comment: Oops, I forgot to update PyInit__Thread() with my new time: - Add PyType_Ready() - Register RLockType to threading dict Here is the new patch -- keywords: +patch Added file: http://bugs.python.org/file11174/rlock.patch ___

[issue3618] possible deadlock in IO library (Lib/io.py)

STINNER Victor <[EMAIL PROTECTED]> added the comment: @pitrou: I wrote an implementation of RLock in C (see #3001). So it would be possible to use threading.RLock instead of threading.Lock ;-) ___ Python tracker <[EMAIL PROTECTED]>

[issue3618] possible deadlock in IO library (Lib/io.py)

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Yes indeed. We could use an RLock to avoid the problem but RLock's are damn slow since they are written in pure Python (see #3001). Rewriting the critical parts of RLock (constructor, acquire(), release(), __enter__(), __exit__()) in C should

[issue3618] possible deadlock in IO library (Lib/io.py)

New submission from STINNER Victor <[EMAIL PROTECTED]>: BufferedWriter from Lib/io.py is thread-safe, but... the Python instruction "with self._write_lock:" could be interrupted when the lock is already acquired. Especially, _lsprof.Profiler() uses ceval hook and is called when the lock is acq