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 Python > RLock, and all the logging machinery in threading. While I agree on removing the unused and potentially problematic debugging machinery, I'm not convinced of the benefits of removing the pure Python RLock implementation. To quote Charles-François from the tracker issue: "Now, the fun part: this affects not only RLock, but every Python code performing "atomic" actions: condition variables, barriers, etc. There are some constraints on what can be done from a signal handler, and it should probably be documented." Remove the pure Python RLock doesn't seem to actually solve anything - it just pushes the problem of fixing the signal interaction back onto third party users that are even more ill-equipped to resolve it than we are. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
