_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 <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 ;-) > > > 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? > -- ಠ_ಠ
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
