139

I am testing Python threading with the following script:

import threading

class FirstThread (threading.Thread):
    def run (self):
        while True:
            print 'first'

class SecondThread (threading.Thread):
    def run (self):
        while True:
            print 'second'

FirstThread().start()
SecondThread().start()

This is running in Python 2.7 on Kubuntu 11.10. Ctrl+C will not kill it. I also tried adding a handler for system signals, but that did not help:

import signal 
import sys
def signal_handler(signal, frame):
    sys.exit(0)
signal.signal(signal.SIGINT, signal_handler)

To kill the process I am killing it by PID after sending the program to the background with Ctrl+Z, which isn't being ignored. Why is Ctrl+C being ignored so persistently? How can I resolve this?

James
  • 32,991
  • 4
  • 47
  • 70
dotancohen
  • 30,064
  • 36
  • 138
  • 197

5 Answers5

222

Ctrl+C terminates the main thread, but because your threads aren't in daemon mode, they keep running, and that keeps the process alive. We can make them daemons:

f = FirstThread()
f.daemon = True
f.start()
s = SecondThread()
s.daemon = True
s.start()

But then there's another problem - once the main thread has started your threads, there's nothing else for it to do. So it exits, and the threads are destroyed instantly. So let's keep the main thread alive:

import time
while True:
    time.sleep(1)

Now it will keep print 'first' and 'second' until you hit Ctrl+C.

Edit: as commenters have pointed out, the daemon threads may not get a chance to clean up things like temporary files. If you need that, then catch the KeyboardInterrupt on the main thread and have it co-ordinate cleanup and shutdown. But in many cases, letting daemon threads die suddenly is probably good enough.

vahid abdi
  • 9,636
  • 4
  • 29
  • 35
Thomas K
  • 39,200
  • 7
  • 84
  • 86
  • 9
    you should mention that by doing this threads are not stopped gracefully and some resources not released. – Tommaso Barbugli May 20 '13 at 10:21
  • 3
    Well, Ctrl-C is never a graceful way to stop anything. I'm not sure what resources would be left - shouldn't the OS reclaim anything when the process exits? – Thomas K May 20 '13 at 17:16
  • 7
    @ThomasK Temporary files created by `tempfile.TemporaryFile()` may be left on disk, for example. – Feuermurmel Aug 25 '13 at 08:58
  • If you don't daemonise am I right in thinking the main thread is 'waiting' just below the last `start()`? Or is it just generally waiting in some other magical state where you can no longer interact with it and it'll only finish after its child threads have? – deed02392 Dec 05 '13 at 16:41
  • 1
    @deed02392 : I don't know exactly what happens to the main thread, but as far as I know you can't do anything with it after it exits. The process will finish when all non-daemon threads have finished; parent-child relationships don't come into that. – Thomas K Dec 06 '13 at 22:22
  • Would adding a `__del__` method to your classes help with the cleanup problem? (i.e. all classes can handle anything that needs to close there?) – vitiral Sep 11 '14 at 17:16
  • 1
    `while threading.active_count() > 1: time.sleep(1)` is a little bit better. **[Original post](http://stackoverflow.com/a/1635084/1115187)** – maxkoryukov Sep 16 '16 at 01:06
  • 8
    Looks like in python3 [you can pass `daemon=True`](https://docs.python.org/3/library/threading.html#threading.Thread) to `Thread.__init__` – Ryan Haining Aug 14 '18 at 00:57
  • @RyanHaining has the right answer for python3 – Roman Sterlin May 24 '23 at 11:17
8

KeyboardInterrupt and signals are only seen by the process (ie the main thread)... Have a look at Ctrl-c i.e. KeyboardInterrupt to kill threads in python

Community
  • 1
  • 1
Jon Clements
  • 138,671
  • 33
  • 247
  • 280
8

I think it's best to call join() on your threads when you expect them to die. I've taken the liberty to make the change your loops to end (you can add whatever cleanup needs are required to there as well). The variable die is checked on each pass and when it's True, the program exits.

import threading
import time

class MyThread (threading.Thread):
    die = False
    def __init__(self, name):
        threading.Thread.__init__(self)
        self.name = name

    def run (self):
        while not self.die:
            time.sleep(1)
            print (self.name)

    def join(self):
        self.die = True
        super().join()

if __name__ == '__main__':
    f = MyThread('first')
    f.start()
    s = MyThread('second')
    s.start()
    try:
        while True:
            time.sleep(2)
    except KeyboardInterrupt:
        f.join()
        s.join()
Neuron
  • 5,141
  • 5
  • 38
  • 59
Johan Snowgoose
  • 386
  • 3
  • 6
  • `while True` is silly, you should `join` directly - and that overriden function is kind of questionable. Maybe `def join(self, force=False): if force: self.die = True` so that `join()` is unchanged by `join(force=True)` kills them. But even then, better to inform *both* threads before joining either one. – o11c Apr 04 '19 at 17:33
2

An improved version of @Thomas K's answer:

  • Defining an assistant function is_any_thread_alive() according to this gist, which can terminates the main() automatically.

Example codes:

import threading

def job1():
    ...

def job2():
    ...

def is_any_thread_alive(threads):
    return True in [t.is_alive() for t in threads]

if __name__ == "__main__":
    ...
    t1 = threading.Thread(target=job1,daemon=True)
    t2 = threading.Thread(target=job2,daemon=True)
    t1.start()
    t2.start()

    while is_any_thread_alive([t1,t2]):
        time.sleep(0)
Neuron
  • 5,141
  • 5
  • 38
  • 59
Hansimov
  • 597
  • 7
  • 10
0

One simple 'gotcha' to beware of, are you sure CAPS LOCK isn't on?

I was running a Python script in the Thonny IDE on a Pi4. With CAPS LOCK on, Ctrl+Shift+C is passed to the keyboard buffer, not Ctrl+C.

Syscall
  • 19,327
  • 10
  • 37
  • 52