> 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
2012/1/8 Matt Joiner :
> 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 Python
> RLock
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
> 2012/1/7 Charl
2012/1/7 Charles-François Natali :
> 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 operation, it's stil
_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 i
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 c
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
> Hi
On Fri, Jan 6, 2012 at 11:17 AM, Antoine Pitrou 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 down in PEP.
On Thu, 5 Jan 2012 15:02:42 -0700
Eric Snow wrote:
> 2012/1/5 Charles-François Natali :
> > 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
2012/1/5 Charles-François Natali :
> 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.
> Whethe
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 practis
11 matches
Mail list logo
