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.
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
Interrupt and sigterm before sigkill kernel. #620
Interrupt and sigterm before sigkill kernel. #620
Changes from all commits
93dd3ac
55ba451
d2c1250
331c558
c91c993
dae1def
d6cd86b
6024cca
60aa969
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I see we prefer
SIGKILL
overkill()
and assume thatkill()
exists. Should we do the same withSIGTERM
andterminate()
? (I suspect this is due to Windows not havingSIGTERM
?)Actually, given that
Popen
is well-documented to useSIGKILL
andSIGTERM
forkill()
andterminate()
, respectively, and there don't appear to be python version compatibility issues, I think we'd be fine just calling the desired methods directly. This would then forgo the need to log anything and remove the conditional attribute checks.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.
Diggning in:
I don't think that's compatibility issue, signal_kernel signal the process group, not the kernel alone.
Sigterm can be handled by a subprocess, not sigkill.
Signal_kernel send the signal to the process group (when possible) instead of only the single process, so if the kernel has children you don't want to send sigterm to the (grand)children, put leave the child process a chance to clean up it children, in case there is some cleanup logic.
Thus
terminate()
is prefered, and if you can't you sigterm the process group.Kill is the opposite, as the kernel has no chance to terminate children by catching sigkill, you want to tell them to die as well. See #314
I guess in a perfect world you would
we just skip 4,4b, and replace 3 by "term child, if you can't term everybody".
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.
Good point on the process group portion of things. I had conflated
signal_kernel()
withsend_signal()
.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.
Yeah, i I had to dig deep in the code and history to figure that one :-)
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.
I think this spin-wait needs to be associated with the
except
block - otherwise, it will occur again for the successful shutdown-request case (which will immediately exit, but probably not the intent).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.
Yeah, it's with the one just below, let me try to change the layout to be clearer.
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.
I've split the two try/except to make the intention clearer, is that better ?
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.
Not super familiar with
gen
from tornado. Is there a risk of issues here depending on the wrapping event loop?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.
I don't believe so, that's the exact way ipykernel uses coroutines:
So if this breaks; IPykernel would be broken, and if it works with ipykernel, I see no reason this wouldn't.
I would prefer
async def
andawait
, but that unfortunately does not mix.