A mechanism is needed to override waiting for Python threads to finish

[michaelahughes]

BPO	10444
Nosy	@amauryfa, @pitrou, @merwok, @florentx, @Vgr255, @JulienPalard
Files	real.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2016-12-01.15:21:23.354>
created_at = <Date 2010-11-17.14:04:16.147>
labels = ['type-feature', 'library']
title = 'A mechanism is needed to override waiting for Python threads to finish'
updated_at = <Date 2016-12-01.15:21:23.352>
user = 'https://bugs.python.org/michaelahughes'

bugs.python.org fields:

activity = <Date 2016-12-01.15:21:23.352>
actor = 'abarry'
assignee = 'none'
closed = True
closed_date = <Date 2016-12-01.15:21:23.354>
closer = 'abarry'
components = ['Library (Lib)']
creation = <Date 2010-11-17.14:04:16.147>
creator = 'michaelahughes'
dependencies = []
files = ['19626']
hgrepos = []
issue_num = 10444
keywords = ['patch']
message_count = 13.0
messages = ['121354', '121355', '121356', '121358', '121359', '121360', '131460', '131462', '145281', '280711', '282107', '282183', '282185']
nosy_count = 7.0
nosy_names = ['amaury.forgeotdarc', 'pitrou', 'eric.araujo', 'flox', 'michaelahughes', 'abarry', 'mdk']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue10444'
versions = ['Python 3.2']

[michaelahughes]

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.

[michaelahughes]

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.

[michaelahughes]

Scratch that last patch. It was missing part of the fix.
I've removed the old patch now, and submitted the proper one.

[amauryfa]

How do you use it?

[michaelahughes]

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

[smontanaro]

Why is setting your threads as daemons not an option?

[michaelahughes]

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.

[pitrou]

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.

[florentx]

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.”

[JulienPalard]

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

[JulienPalard]

If nobody has nothing to add on this issue, I think it just should be closed.

[michaelahughes]

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\>

---

[Vgr255]

Let's just close this.