What happens to other threads when main thread calls sys.exit()?

11
votes

From the docs: http://docs.python.org/2/library/thread

When the main thread exits, it is system defined whether the other threads survive. On SGI IRIX using the native thread implementation, they survive. On most other systems, they are killed without executing try ... finally clauses or executing object destructors.

And here, in the docs (http://docs.python.org/2/library/threading) it says:

A thread can be flagged as a “daemon thread”. The significance of this flag is that the entire Python program exits when only daemon threads are left. The initial value is inherited from the creating thread.

Let's talk only about non-daemon threads here. Since, the first quote does not make any special reference to non-daemon threads, I would assume that even non-daemon threads should be killed if the main thread is exiting. However, the second quote suggests otherwise. And in fact, the non-daemon threads are indeed not killed when the main thread exits. So, what's the point of first quote here?

1
pythonmultithreadingpython-2.7daemonexit
Write code and try it out – Andreas Jung
It would seem that the thread module handles everything as daemon threads, while threading adds the concept of "non daemon" threads. – Joachim Isaksson
@user2799617: I did write code and came to the conclusion "the non-daemon threads are indeed not killed when the main thread exits". That's why, I am wondering when does the first quote apply since my system is probably one of those "most other systems": Ubuntu 12.10 running python 2.7 – gjain
@JoachimIsaksson: Thanks, that does make sense. I suspected that, but just needed a confirmation – gjain
@gjain If you read the last part of the threading page, there's some interesting info equalling daemon threads with thread module created threads; "This can be most easily achieved by only performing imports from non-daemon threads created through the threading module. Daemon threads and threads created directly with the thread module will require some other form of synchronization to ensure they do not attempt imports after system shutdown has commenced." – Joachim Isaksson

1 Answers

10
votes

The documentation you reference comes from two different modules: thread and threading. thread is a low-level module providing more-or-less direct access to the platform's idea of what "thread" means. threading supplies a higher-level notion of "thread" with less platform dependence.

That's why the docs say different things. What happens to a low-level thread "thread" at exit does depend on what the platform C's version of threads do, but in any case Python makes no attempt to - or not to - shut them down cleanly.

A threading.Thread is different. Part of Python's normal shutdown processing is to .join() all non-daemon threading.Thread threads. So the program won't end at all until all non-daemon threading.Thread threads have ended (which is the programmer's responsibility to ensure). Note that the low-level thread module threads have no concept of .join() - .join() is a higher-level concept implemented by the distinct threading module.

Advice: use threading instead of thread unless you have excellent reasons to use thread instead. threading is better behaved and supplies many useful tools. An example of when using thread is better? I can't think of one ;-)

Note: in Python 3, the low-level thread module is renamed to _thread. As usual, the leading underscore hints "better not to mess with this - but it's here if you must".