Allow killing processes with SIGTERM
#358
Closed
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.
Branched from #357
Add
cleanup_signalargument torun()andprocess$new(). This instructs processx to use softer termination on GC so that the callr cleanup handler may run.Add
signalarguments tokill()andkill_tree()methods. Used internally to support the above, and externally by event loops.Since the kill signal may now be ignored by the process, poll for
SIGCHLDwith a timeout. This is implemented usingprocess_wait()and tested with a new dynlibsigtermignorethat installs aSIGTERMhandler that ignores the signal.I'm not 100% happy with the API implemented here. I can call
kill_tree(signal = SIGTERM)in an event loop and register a subsequentSIGKILLwith a delay, this part is fine. However, when processes created withcleanup_signal = SIGTERMfail to properly quit on GC, the processes might not be killed. Also it seems thatclose_connections = TRUEalso causes the process to finish (e.g. it causes processes linked to sigtermignore to terminate), and I'm not sure how this interacts with SIGTERM cleanup.Would it make sense to revive the
graceargument and do staged termination with SIGTERM and SIGKILL by default?