This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Windows: Unclear behavior of daemon threads on main thread exit
Type: behavior Stage: needs patch
Components: Documentation, Windows Versions: Python 3.4, Python 3.5, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Vandana.Rao, docs@python, eric.snow, etuardu, paul.moore, r.david.murray, steve.dower, tim.golden, vstinner, zach.ware
Priority: normal Keywords:

Created on 2011-09-30 15:30 by etuardu, last changed 2022-04-11 14:57 by admin.

Files
File name Uploaded Description Edit
foo.py etuardu, 2011-10-01 13:43
Messages (7)
msg144691 - (view) Author: etuardu (etuardu) Date: 2011-09-30 15:30
The definition of daemon thread in the current documentation reads:

«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. [...]»
(http://docs.python.org/library/threading.html#thread-objects)

I think it's not very clear from this that daemon threads themselves terminate when the program (main thread plus other non-daemon threads) terminates. I think this have to be said more explicitly. I'd propose a change with something like:

«A thread can be flagged as a "daemon thread", which means it will get shut down when the overall program terminates. The entire Python program exits when only daemon threads are left.»
msg144692 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-09-30 15:42
It seems clear enough to me that when a process terminates ("the entire Python program exits") then all of its threads must terminate.  That's part of the definition of threads, to my understanding.

I think the confusion arises from the use of the word "deamon", which has been discussed as a bad thing elsewhere in this tracker.  A unix user would expect a "daemon" to keep running in the background, whereas here it is exactly the opposite.  See issue 5906 for example, where in the context of Multiprocessing it becomes even more confusing.  Perhaps a similar note that 'daemon' does not mean what it does in unix would be a good idea.
msg144730 - (view) Author: etuardu (etuardu) Date: 2011-10-01 13:43
Let me put it this way: the definition of daemon thread describes the behaviour of the Python program running it (its exit condition in particular) instead of going straight to the point describing the behaviour of the daemon thread itself first, and finally add other considerations.

Specifically, I think a situation like the following is not quite clear from the given definition:
- I have a main thread and a secondary thread, both printing to stdout.
- At some point, I press Ctrl+c raising an unhandled KeyboardInterrupt exception in the main thread, which kills it.

This is what I get using a daemon thread:

etuardu@subranu:~/Desktop$ python foo.py # other = daemon
other thread
main thread
other thread
main thread
^C
Traceback [...]
KeyboardInterrupt
etuardu@subranu:~/Desktop$ # process terminates

This is what I get using a non-daemon thread:

etuardu@subranu:~/Desktop$ python foo.py # other = non-daemon
other thread
main thread
other thread
main thread
^C
Traceback [...]
KeyboardInterrupt
other thread
other thread
other thread
... (process still running)

So, to explain the significance of the "daemon" flag, I'd say something like:

A daemon thread is shut down when the main thread and all others non-daemon threads end.
This means a Python program runs as long as non-daemon threads, such as the main thread, are running.
When only daemon threads are left, the Python program exits.

Of course this can be understood from the current definition («the entire Python program exits when only daemon threads are left»), still it looks a bit sybilline to me.
msg233285 - (view) Author: Vandana Rao (Vandana.Rao) * Date: 2015-01-01 15:32
On Windows8.1,this is not the situation.Irrespective of the thread being daemon or non-daemon,the process continues. The program doesn't terminate when daemon thread is being used.
msg233286 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-01-01 15:56
etuardu: I think you rewording is indeed clearer.

Vandana: Please open a new issue with a reproducer.
msg236606 - (view) Author: Vandana Rao (Vandana.Rao) * Date: 2015-02-25 17:25
Since the program depends on receiving a raw ^C == 0x03 on stdin, it will never be running under Idle because the Idle process tk gui normally keeps control of keyboard input and the Idle process code intercepts ^C and turns it into KeyboardInterrupt raised in the user process.
This is not a bug anymore.It is working fine.
msg363719 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-03-09 11:28
I can only reproduce the behavior (other thread continues to run after CTRL+C) on Windows, not on Linux.
History
Date User Action Args
2022-04-11 14:57:22adminsetgithub: 57286
2020-03-09 11:28:30vstinnersettitle: Unclear behavior of daemon threads on main thread exit -> Windows: Unclear behavior of daemon threads on main thread exit
nosy: + paul.moore, tim.golden, vstinner, zach.ware, steve.dower

messages: + msg363719

components: + Windows
2019-12-20 23:21:06eric.snowsetnosy: + eric.snow
2015-02-25 17:25:02Vandana.Raosetmessages: + msg236606
2015-01-01 15:56:16r.david.murraysetstage: patch review -> needs patch
messages: + msg233286
versions: + Python 3.4, Python 3.5, - Python 3.2, Python 3.3
2015-01-01 15:32:05Vandana.Raosetnosy: + Vandana.Rao
messages: + msg233285
2011-10-01 13:43:58etuardusetfiles: + foo.py

messages: + msg144730
2011-09-30 15:42:48r.david.murraysetversions: - Python 2.6, Python 3.1, Python 3.4
nosy: + r.david.murray

messages: + msg144692

stage: patch review
2011-09-30 15:30:41etuarducreate