-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
bpo-38356: Fix ThreadedChildWatcher thread leak in test_asyncio #16552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
miss-islington
merged 5 commits into
python:master
from
aeros:bpo38356-fix-test_subprocess
Jan 12, 2020
+8
−1
Merged
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
4a8395a
Fix test_asyncio.test_subprocess dangling threads
aeros bfc0d6c
Remove empty line and fix formatting
aeros fbf7f0d
Fix code formatting
aeros 6bcf009
Don't join daemon threads
aeros fe2b256
Add docstring for ThreadedChildWatcher._join_threads()
aeros File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Fix code formatting
- Loading branch information
commit fbf7f0dd76531a9a6028cc21eebb087b817966a9
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to remove the thread from self._threads as soon as a thread complete?
Would it be possible to log a warning if a thread runs longer than timeout seconds? Or even exit silently if the timoeut is exceeded?
Maybe we should also modify add_child_handler() to raise an exception if it's called after close() has been called? For example, add a _closed attribute? It would prevent to spawn new threads while we wait for existing threads.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vstinner
Yeah sure, I would have no issue with adding something like this. I'm not 100% sure that we have to remove the threads that aren't alive from
self._threads
, but it would certainly be possible.What exactly does removing the threads from
self._threads
accomplish that joining them doesn't already do? When a thread is successfully joined,thread._is_stopped
is set to true, which is whatthread.is_alive()
uses to check if the thread is still active. I don't think we necessarily need to remove the threads fromself._threads
as part of the cleanup. Unless there's something I'm missing, I think that would just add additional overhead.This should be possible by running
thread.join(timeout)
and ifthread.is_alive()
is True afterwards, the join timed out. In what situations would you want to differentiate between logging a warning vs silently exiting?Unless by "exit silently" you were referring to
thread.join()
, which effectively does that already when the timeout is reached.thread.join(timeout)
will block for timeout duration or when the join is complete, whichever one occurs first.Yeah this would be a fairly straightforward change and I agree with it. A
RuntimeError
would be suitable as an exception to raise for that scenario.