In the Python documentation:
http://www.python.org/doc/2.5.2/lib/thread-objects.html
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."
Does anyone have a clearer explanation of what that means or a practical example showing where you would want to set threads as daemonic?
-
Some threads do background tasks, like sending keepalive packets, or performing periodic garbage collection, or whatever. These are only useful when the main program is running, and it's okay to kill them off once the other, non-daemon, threads have exited.
Without daemon threads, you'd have to keep track of them, and tell them to exit, before your program can completely quit. By setting them as daemon threads, you can let them run and forget about them, and when your program quits, any daemon threads are killed automatically.
-
Let's say you're making some kind of dashboard widget. As part of this, you want it to display the unread message count in your email box. So you make a little thread that will:
- Connect to the mail server and ask how many unread messages you have.
- Signal the GUI with the updated count.
- Sleep for a little while.
When your widget starts up, it would create this thread, designate it a daemon, and start it. Because it's a daemon, you don't have to think about it; when your widget exits, the thread will stop automatically.
-
A simpler way to think about it, perhaps: when main returns, your process will not exit if there are non-daemon threads still running.
A bit of advice: Clean shutdown is easy to get wrong when threads and synchronization are involved - if you can avoid it, do so. Use daemon threads whenever possible.
-
to clarify for me:
so the only time you "wouldn't" set threads as daemonic is if you wanted them to continue running after the main thread exits?
giltay : I think that's fair. If a thread needs to do some clean-up action after it's done, for instance, you wouldn't want it dæmonic. I think it's more important in interactive programmes, where the user expects it to shut down when the GUI is closed, for example.Chris Jester-Young : I would put it this way: is a thread part of the "main functionality" of a program? (i.e., should its existence keep the program running?) If so, it's a non-daemon thread. (Example in next comment, running out of chars here.)Chris Jester-Young : Example: A web server may have a thread pool to service multiple web requests at once. This thread pool should not be in daemon mode. That way, when the web server is restarted, existing web requests will get to finish first.Chris Jester-Young : Otherwise, when your user has spent the last 5 hours writing their blog post (or whatever) and then find that the server has "eaten" their post (they'll see a "connection reset" message, if the connection is killed), your head will be on a platter, so to speak. :-P -
Other posters gave some examples for situations in which you'd use daemon threads. My recommendation, however, is never to use them.
It's not because they're not useful, but because there are some bad side effects you can experience if you use them. Daemon threads can still execute after the Python runtime starts tearing down things in the main thread, causing some pretty bizarre exceptions.
More info here:
http://joeshaw.org/2009/02/24/605
http://mail.python.org/pipermail/python-list/2005-February/307042.html
Strictly speaking you never need them, it just makes implementation easier in some cases.
0 comments:
Post a Comment