[Tim] > I'm deadly opposed to letting a keyboard interrupt break out of a > wait for a Python lock. I've heard this before. Can you explain why? It would not be incorrect -- if the SIGINT had arrived a microsecond before the wait started, the program would have been interrupted in exactly the same state. It's one of the few places where code can be blocked in a system call (if you want to call a lock wait a system call -- it's close enough for me) and a ^C doesn't stop it, and that can be annoying at times. Of course, if it's not the main thread, signals including SIGINT shouldn't do anything, but that's a separate issue. Breaking the main thread IMO is useful behavior for interactive programs and for scripts invoked from the command line. (In practice, this is probably only interesting for interactive use -- if you hang your main thread on a deadlock, there's no way to get your >>> prompt back, and that may mean no way to figure out what went wrong or save stuff you wanted to save. --Guido van Rossum (home page: http://www.python.org/~guido/)
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