1

I recently answered a question here

The question was: how to interrupt a python script when a subprocess is running (possibly windows-specific).

I suggested to create a thread to run the subprocess on, and wait on the mainloop for CTRL+C / KeyboardInterrupt exception so the child process can be killed.

It works, but bit of a hack because I did this: Basically, I make a non-cpu active (but polling) loop which waits 100ms then checks for the shared boolean done. If the subprocess exits, the thread sets done. If CTRL+C is pressed, the main process goes in the exception handler and kills the process.

...

t = threading.Thread(target=s)
t.start()


try:
    while not done:
        time.sleep(0.1)

except KeyboardInterrupt:
    print("terminated")
    proc.terminate()
...

I wanted to improve it to use thread locks. So I rewrote it, looks clean, not so much shared variables, no more time loops, looks ideal, except that ... it doesn't work. CTRL+C is not responding while in the lock.acquire() of the main loop.

import subprocess
import threading

import time

binary_path = 'notepad'
args = 'foo.txt' # arbitrary

proc = None

lock = threading.Lock()

def s():
    call_str = '{} {}'.format(binary_path, args)
    global proc
    proc = subprocess.Popen(call_str,stdout=subprocess.PIPE)
    proc.wait()
    lock.release()

lock.acquire()

t = threading.Thread(target=s)
t.start()

try:
    lock.acquire()   # CTRL+C is inoperant here

except KeyboardInterrupt:
    print("terminated")
    proc.terminate()

I saw this question which makes me think that my time loop isn't that bad after all. The thread lock is probably executing Windows code (not Python) and not responding to CTRL+C. In that case, why can I interrupt a time.sleep() ?

Is there a way to make it work with clean OS calls ?

Community
  • 1
  • 1
Jean-François Fabre
  • 137,073
  • 23
  • 153
  • 219
  • Just tested this code on Linux and Ctrl-C works. – akraf Sep 17 '16 at 09:01
  • Can't test it (see above), but have you looked into the `signal` module? You could define a function which kills the child thread and set it using `import signal as s; s.signal(s.CTRL_C_EVENT, yourfunction)` (don't know if you need `s.SIGINT` or `s.CTRL_C_EVENT`) – akraf Sep 17 '16 at 09:04
  • @akraf: thanks but no way! same thing. Signal is blocked. I suppose that if `KeyboardInterrupt` doesn't work, then game over. – Jean-François Fabre Sep 17 '16 at 09:36
  • Ctrl+C and Ctrl+Break aren't implemented as OS signals on Windows. They're console control events which start in conhost.exe (the Windows equivalent of an xterm) and get sent over to the session's server process, csrss.exe. This in turn creates a *new thread* in the target process, starting at the `CtrlRoutine` function in kernel32.dll. The only time Ctrl+C actually interrupts the main thread directly is when it's reading from the console input buffer. – Eryk Sun Sep 17 '16 at 16:00
  • @eryksun I was suspecting that, since signals are already emulated in MSYS (read: don't work). I just wonder why you did not post that command as an answer as it looks a lot like it. – Jean-François Fabre Sep 17 '16 at 16:05
  • Windows console programs set handler functions for control events via `SetConsoleCtrlHandler`. The C runtime sets a handler that maps `CTRL_C_EVENT` to C `SIGINT` and `CTRL_BREAK_EVENT` to (non-standard) `SIGBREAK`. Python in turn has a C signal handler. Say a `SIGINT` comes in on a new thread. The handler sets a flag to let `PyErr_CheckSignals`, when called on the main thread, know that it should call Python's registered `SIGINT` handler, which may or may not raise an exception (e.g. `KeyboardInterrupt`) . – Eryk Sun Sep 17 '16 at 16:08
  • In addition to setting the flag, the signal handler also sets a Windows event object. Other code that waits on the main thread can wait on this event. That's how `time.sleep` is implemented when called on the main thread. It waits on the event with the given timeout. When the event is signaled it calls `PyErr_CheckSignals` to see if an exception was raised that should break out of the sleep. If not it resumes waiting. – Eryk Sun Sep 17 '16 at 16:11
  • Waiting on the threading lock currently only waits on a single object (a mutex I think). To be interruptible by Ctrl+C it needs to be rewritten to call `WaitForMultipleObjects` to wait on the mutex plus the `SIGINT` event. – Eryk Sun Sep 17 '16 at 16:15

0 Answers0