(original) (raw)

_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 if you removed \_PyRLock, these implementations would have to expose their own RLock primitive which works the same way as the one just removed from the standard library. I don't know if this is a good thing.

I would recommend checking with at least the gevent and eventlet developers.

2012/1/7 Charles-François Natali <neologix@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 ;-)

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

Sorry, I'm not sure I understand. Do those projects use \_PyRLock directly?
If yes, then aliasing it to \_CRLock should do the trick, no?

--
ಠ\_ಠ