[Python-Dev] usefulness of Python version of threading.RLock (original) (raw)

Matt Joiner anacrolix at gmail.com
Sat Jan 7 01:10:17 CET 2012

_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 at 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?

-- ಠ_ಠ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120107/edbd5e6d/attachment.html>

More information about the Python-Dev mailing list