2012/1/8 Matt Joiner <anacrolix at 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 | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4