git-annex/doc/todo/ctrl_c_propagation_to_transferrer_process.mdwn
Joey Hess d3f78da0ed
propagate signals to the transferrer process group
Done on unix, could not implement it on windows quite.

The signal library gets part of the way needed for windows.
But I had to open https://github.com/pmlodawski/signal/issues/1 because
it lacks raiseSignal.

Also, I don't know what the equivilant of getProcessGroupIDOf is on
windows. And System.Process does not provide a way to send any signal to
a process group except for SIGINT.

This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.
2020-12-11 15:32:00 -04:00

28 lines
1.5 KiB
Markdown

When annex.stalldetection is set, and git-annex transferrer is used,
a ctrl-c does not propagate to the transferrer process.
The result is that, the next time the process sends a message to its output
handle (eg a progress update), it gets a SIGINT, and so an ugly message is
output to the console, after the user was returned to the prompt.
The SIGINT is not propagated because a child process group is used for
git-annex transferrer, in order to let child processes of it be killed
along with it when a stall is detected.
Maybe what's needed is a SIGINT handler in the main git-annex that
signals all the transferrer processes with SIGINT and waits on them
exiting. And other signals, eg SIGTSTP for ctrl-z.
> Implemented this, but not for windows (yet). But not gonna leave open
> for something that on windows in my experience does not work very
> reliably in general. (I've many times hit ctrl-c in a windows terminal and
> had the whole terminal lock up.) So, [[done]] --[[Joey]]
Or, note that it would suffice to remove the child process group stuff,
if we assume that all child processes started by git-annex transferrer are
talking to a pipe, and will output something, eg a progress update,
and so receive a SIGPIPE once the transferrer process has caught the
SIGINT and exited.
[[todo/stalldetection_does_not_work_for_rsync_and_gcrypt]] would be a
prereq for this approach. But, might there be long-running child processes
that are not on a pipe, and that need to be shutdown on a stall, too?