Issue 10444: A mechanism is needed to override waiting for Python threads to finish (original) (raw)

Created on 2010-11-17 14:04 by michaelahughes, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
real.patch michaelahughes,2010-11-17 14:13
Messages (13)
msg121354 - (view) Author: Michael Hughes (michaelahughes) Date: 2010-11-17 14:04
We use the Python interpreter embedded in our application, and would prefer to not block an exit of our application waiting for non-daemon threads to finish. I would like a mechanism exposed that queries for whether or not to wait.
msg121355 - (view) Author: Michael Hughes (michaelahughes) Date: 2010-11-17 14:11
I have a patch here. It is to allow for a callback to be set on the main thread which gets called when there are non-daemon threads still alive on exit. The callback returns True or False indicating whether or not it wants to block. By default, the whole thing blocks.
msg121356 - (view) Author: Michael Hughes (michaelahughes) Date: 2010-11-17 14:13
Scratch that last patch. It was missing part of the fix. I've removed the old patch now, and submitted the proper one.
msg121358 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-11-17 14:20
How do you use it?
msg121359 - (view) Author: Michael Hughes (michaelahughes) Date: 2010-11-17 14:25
To use the callback, you can do this: import threading def threadendcallback(): # return False to indicate that we don't # want to wait for any threads before exiting return False threading.currentThread().waitForThreadsOnExitFunc = threadendcallback
msg121360 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2010-11-17 14:27
Why is setting your threads as daemons not an option?
msg131460 - (view) Author: Michael Hughes (michaelahughes) Date: 2011-03-19 23:04
Hey guys We don't always have control over all of the threads launched within our application. We might have inexperienced users writing basic scripts using threads, but they don't know enough about setting them to Daemon. Previous versions of the Python interpreter we were using in our app didn't block. I'd like an option to override the blocking, because for our application, for the most part, we do want it to always quit and not wait for threads to quit properly.
msg131462 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-03-19 23:08
This looks like an ugly hack to solve a slightly exotic problem. You could instead enumerate() all threads and set their daemon flag to False, before shutting down the interpreter.
msg145281 - (view) Author: Florent Xicluna (flox) * (Python committer) Date: 2011-10-09 21:40
Antoine wrote: > You could instead enumerate() all threads and set their daemon flag > to False, before shutting down the interpreter. If it is intended to work this way, it should be mentioned in the documentation. Currently the documentation for "Thread.daemon" says: “This must be set before start() is called, otherwise RuntimeError is raised.”
msg280711 - (view) Author: Julien Palard (mdk) * (Python committer) Date: 2016-11-13 20:17
`daemon` flag cannot be changed after thread is started, the documentation is right and the code of the daemon setter is actually: if self._started.is_set(): raise RuntimeError("cannot set daemon status of active thread") But still it looks like a code review problem: all your daemonic threads should be created as daemonic. Breaking the `daemon` semantics looks like a bug magnet: any future uses of non-daemonic threads (by an "experienced" developer of your team, specifically needing a non-daemon thread for a specific task) will behave as a deamon thread and the specific task may not be correctly executed (like, logging an exception?).
msg282107 - (view) Author: Julien Palard (mdk) * (Python committer) Date: 2016-11-30 21:58
If nobody has nothing to add on this issue, I think it just should be closed.
msg282183 - (view) Author: Michael Hughes (michaelahughes) Date: 2016-12-01 15:17
Given that this is from five years ago, and I've moved on, I honestly can't say I care too deeply about this. My use case was for handling threads: * created by inexperienced python programmers that don't know about daemons * using third party python scripts that it would be easier not to edit I feel that my proposed change handles that in a reasonable way, and doesn't complicate the interface for threads terribly. Most users can completely ignore the new method I proposed, and it won't affect them. For those going to look for it, it'll be there. But again, I'm not even working in Python and no one else has chimed in on this in five years. Does it matter anymore? - Michael > On Nov 30, 2016, at 1:58 PM, Julien Palard <report@bugs.python.org> wrote: > > > Julien Palard added the comment: > > If nobody has nothing to add on this issue, I think it just should be closed. > > ---------- > > _______________________________________ > Python tracker <report@bugs.python.org> > <http://bugs.python.org/issue10444> > _______________________________________
msg282185 - (view) Author: Anilyka Barry (abarry) * (Python triager) Date: 2016-12-01 15:21
Let's just close this.
History
Date User Action Args
2022-04-11 14:57:09 admin set github: 54653
2016-12-01 15:21:23 abarry set status: open -> closednosy: + abarrymessages: + resolution: rejectedstage: resolved
2016-12-01 15:17:53 michaelahughes set messages: +
2016-11-30 21:58:10 mdk set messages: +
2016-11-13 20:17:52 mdk set nosy: + mdkmessages: +
2011-10-09 21:40:11 flox set nosy: + floxmessages: +
2011-03-19 23:08:54 pitrou set nosy: + pitroumessages: +
2011-03-19 23:04:38 michaelahughes set messages: +
2011-03-19 19:09:57 skip.montanaro set nosy: - skip.montanaro
2010-11-18 13:33:11 eric.araujo set nosy: + eric.araujoversions: - Python 2.6, Python 3.1, Python 2.7, Python 3.3
2010-11-17 14:27:51 skip.montanaro set nosy: + skip.montanaromessages: +
2010-11-17 14:25:03 michaelahughes set messages: +
2010-11-17 14:20:15 amaury.forgeotdarc set nosy: + amaury.forgeotdarcmessages: +
2010-11-17 14:14:04 michaelahughes set files: - threadingchange.patch
2010-11-17 14:13:58 michaelahughes set files: + real.patchmessages: +
2010-11-17 14:11:11 michaelahughes set files: + threadingchange.patchkeywords: + patchmessages: +
2010-11-17 14:04:16 michaelahughes create