So while SIGINT is present on all systems and can be handled and caught, the SIGBREAK signal is Windows specific (and can be disabled in CONFIG.SYS) and is really handled by the BIOS as an interrupt vector INT 1Bh, which is why this key is much more powerful than any other. For example, on Windows machines we have Ctrl+ C ( SIGINT) and Ctrl+ Break ( SIGBREAK). So you will have very different behavior depending on where you run your python script. The interrupt process is hardware and OS dependent. The first of the KeyboardInterrupt exceptions will knock your program out of the try block and hopefully one of the later KeyboardInterrupt exceptions will be raised when the program is outside of a try block. If you can't change the code (or need to kill the program so that your changes will take effect) then you can try pressing Ctrl + c rapidly. A properly coded python program will make use of the python exception hierarchy and only catch exceptions that are derived from Exception.
If the except part of the try- except block doesn't specify which exceptions it should catch, it will catch all exceptions including the KeyboardInterrupt that you just caused. It's likely that a program that makes lots of HTTP requests will have lots of exception handling code. :P I filed MSFT:10626321 to my backlog to make sure that I think about it at some point in the future.Pressing Ctrl + c while a python program is running will cause python to raise a KeyboardInterrupt exception. I doubt it is a problem, but I've said that about other things in the past and they bit me later. :( I'd have to think about it and dig in a bit. I'm also not sure whether fixing it will cause a compatibility nightmare elsewhere with someone who now relies on the existing behavior. I'm not sure whether it's intentional or a mistake that the API doesn't release the ReadConsole wait handles. Regarding GenerateConsoleCtrlEvent, I agree it probably should act the same as pressing it on the keyboard. Re-working the locks to be more reliable is on my backlog but keeps getting out-prioritized by other stuff. The lag might have something to do with the miserable locking mechanism inside the console, but there's not a ton I can do about that anytime soon. We're writing tests right now to simulate various SendMessage keys like that anyway, I'll make sure your case is in there as well.
If it always used to work, we should make an effort to keep it working.
:P If you can get the Windows Insiders ISO, sometimes it's easier to clean install or upgrade install with that using the setup.exe on the disc using SendMessage should be fine for the majority case. I also have to sacrifice a goat to make Windows Update work properly on my machine sometimes.
0 kommentar(er)
