keyboardinterrupt

I have a GUI application written with python+tkinter. In my workflow, I generally start the gui from the commandline, do some things in the gui and then I find myself navigating to other terminal windows to do some work. Inevitably, I want to shut down the GUI at some point, and out of habit I often just navigate to the terminal that started the GUI and send a KeyboardInterrupt (Ctrl-c). However, This interrupt is not recieved until I raise the GUI window in the Window manager. Does anyone know why this happens? If the gui is started in a single function, is there a simple workaround --

I'm making a simple multi-threaded port scanner. It scans all ports on host and returns open ports. The trouble is interrupting the scan. It take a lot of time for a scan to complete and sometimes I wish to kill program with C-c while in the middle of scan. Trouble is the scan won't stop. Main thread is locked on queue.join() and oblivious to KeyboardInterrupt, until all data from queue is processed thus deblocking main thread and exiting program gracefully. All my threads are daemonized so when main thread dies they should die with him. I tried using signal lib, no success. Overriding

I am experiencing some issues that I suspect is a limitation of my python program to handle correctly, my program is not been able to call methods of a registered class of BaseManager immediately after I hit Ctrl-C, even other process implemented as classes that inherit from multiprocessing.Process are affected. I have some methods that I would like to call from process that don't execute correctly after Ctrl-C. For example the following code is not able to call the mt instance of TestClass after Ctrl-C. from multiprocessing.managers import BaseManager, NamespaceProxy import time class

When entering an inteerupt handler, we first "disable interrupts" on that cpu(using something like the cli instruction on x86). During the time that interrupts are disabled, assume say the user pressed the letter 'a' on the keyboard that would usually cause an interrupt. But since interrupts are disabled, does that mean that: the interrupt handler for 'a' would never be invoked, since interrupts are disabled in the critical section or the interrupt will be handled by the os but delayed, until interrupts are enabled again. Specifically, will the user need to press 'a' again, if the first time

I am currently working on a wrapper for a dedicated server running in the shell. The wrapper spawns the server process via subprocess and observes and reacts to its output. The dedicated server must be explicitly given a command to shut down gracefully. Thus, CTRL-C must not reach the server process. If I capture the KeyboardInterrupt exception or overwrite the SIGINT-handler in python, the server process still receives the CTRL-C and stops immediately. So my question is: How to prevent subprocesses from receiving CTRL-C / Control-C / SIGINT? robert Somebody in the #python IRC-Channel

I have this really small test program which does nothing apart from a executing an asyncio event loop: import asyncio asyncio.get_event_loop().run_forever() When I run this program on Linux and press Ctrl + C , the program will terminate correctly with a KeyboardInterrupt exception. On Windows pressing Ctrl + C does nothing (tested with Python 3.4.2). A simple inifinite loop with time.sleep() raises the KeyboardInterrupt correctly even on Windows: import time while True: time.sleep(3600) Why does the asyncio's event loop suppress the KeyboardInterrupt on Windows? This is a bug, sure. See issue

I have been debugging a Python program which segfaults after receiving a KeyboardInterrupt exception. This is normally done by pressing Ctrl+C from the shell. To test if a particular code change fixed the bug, I had a small shell-script that sent SIGINT to the program at random time after start-up. The problem I have is that sending Ctrl+C seems to have a different effect on the program than sending the signal SIGINT and is thus not causing the bug to appear, so I quite wonder what the difference is then between the two actions. The program does not catch any keyboard actions at all, and is