Martin v. Löwis wrote: > asynchronous exceptions in a sensible way. I have to research somewhat > more, but I think the standard solution to the problem in operating > system (i.e. disabling interrupts at certain points, explicitly > due to code or implicitly as a result of entering the interrupt > handler) may apply. Two already working schemes, that are similar, comes to my mind. One is signals in Linux/Unix, where you can send SIGTERM, and the process can handle it and do whatever it takes. But also you can send SIGKILL, which can not be blocked. The other is microprocessors, where you have interrupts, and when the interrupt is received, you disable it (are there processors that support "reentrant" interrupts? I don't know of any, but I'm no specialist here). To me, is natural this behaviour: One can send ThreadDeath to the thread, and it can handle it or no. If not, it dies. If yes, it does some stuff and dies. But if I send a second ThreadDeath to the same thread, when it's still "dying", for me it's ok to receive an answer like "Ok, ok, I heard you, I'm on it". But, in that scenario, should be a way to say to the thread "Die, die now, no matter what"? Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
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