2020-12-10 21:46:58 +00:00
|
|
|
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
|
2020-12-11 19:28:58 +00:00
|
|
|
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]]
|
2020-12-10 21:46:58 +00:00
|
|
|
|
|
|
|
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?
|