| 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) *  |
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) * |
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) * |
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. |
|
|