The yes/no answer is No, we can't drop it.
Thanks, that's a clear answer :-)
I'm not convinced of the benefits of removing the pure Python RLock
implementation
Indeed.
As noted, this issue with signal handlers is more general, so this
wouldn't solve the problem at hand. I just wanted to know
2012/1/7 Charles-François Natali neolo...@free.fr:
Thanks for those precisions, but I must admit it doesn't help me much...
Can we drop it? A yes/no answer will do it ;-)
The yes/no answer is No, we can't drop it.
Even though CPython no longer uses the Python version of RLock in
normal
Nick did you mean to say wrap python code around a reentrant lock to
create a non-reentrant lock? Isn't that what PyRLock is doing?
FWIW having now read issues 13697 and 13550, I'm +1 for dropping Python
RLock, and all the logging machinery in threading.
2012/1/8 Nick Coghlan ncogh...@gmail.com
2012/1/8 Matt Joiner anacro...@gmail.com:
Nick did you mean to say wrap python code around a reentrant lock to create
a non-reentrant lock? Isn't that what PyRLock is doing?
Actually, I should have said recursive, not reentrant.
FWIW having now read issues 13697 and 13550, I'm +1 for dropping
Thanks for those precisions, but I must admit it doesn't help me much...
Can we drop it? A yes/no answer will do it ;-)
I'm pretty sure the Python version of RLock is in use in several alternative
implementations that provide an alternative _thread.lock. I think gevent
would fall into this
_PyRLock is not used directly. Instead, no _CRLock is provided, so the
threading.RLock function calls _PyRLock.
It's done this way because green threading libraries may only provide a
greened lock. _CRLock in these contexts would not work: It would block the
entire native thread.
I suspect that
Hi,
Issue #13697 (http://bugs.python.org/issue13697) deals with a problem
with the Python version of threading.RLock (a signal handler which
tries to acquire the same RLock is called right at the wrong time)
which doesn't affect the C version.
Whether such a use case can be considered good
2012/1/5 Charles-François Natali neolo...@free.fr:
Hi,
Issue #13697 (http://bugs.python.org/issue13697) deals with a problem
with the Python version of threading.RLock (a signal handler which
tries to acquire the same RLock is called right at the wrong time)
which doesn't affect the C
On Thu, 5 Jan 2012 15:02:42 -0700
Eric Snow ericsnowcurren...@gmail.com wrote:
2012/1/5 Charles-François Natali neolo...@free.fr:
Hi,
Issue #13697 (http://bugs.python.org/issue13697) deals with a problem
with the Python version of threading.RLock (a signal handler which
tries to
On Fri, Jan 6, 2012 at 11:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
From what I understand, the biggest motivation for pure Python
versions is cooperation with the other Python implementations. See
http://www.python.org/dev/peps/pep-0399/
Apologies, I didn't remember it was written
I'm pretty sure the Python version of RLock is in use in several
alternative implementations that provide an alternative _thread.lock. I
think gevent would fall into this camp, as well as a personal project of
mine in a similar vein that operates on python3.
2012/1/6 Charles-François Natali
11 matches
Mail list logo
