Control-C can fail to stop fd

[Porkepix]

With latest stable fd version:

$ fd --version
fd 7.3.0

After several tests, while it seems that a simple call to fd can be interrupted with control-c, although sometimes having a short lag, a call to fd foo / for example just fail to be interrupted by control-c and have to be manually killed by some other ways.

[sharkdp]

Thank you for reporting this.

I think fd currently only shuts down (after Ctrl-C was pressed) when a new search result is available. That is usually fine if there are many search results (such as when running a plain fd), but not acceptable when searching for something really specific (or without any search results).

This is something that should be fixed.

[tavianator]

I have no problem interrupting something like fd asdfasdfasdf / with ^C even though there are no matches.

[sharkdp]

@tavianator You are right, my comment above is not quite correct. The current behavior is better described below. I usually have no problem to Ctrl-C cancel fd, but I have experienced hangs which can not be canceled.

fd has a single receiver thread (that handles the output) and multiple sender threads (that receive file system entries and do the actual work). All threads share a (smart pointer to a) global atomic variable wants_to_quit. When Ctrl-C is pressed, wants_to_quit is set to true by the signal handler.

• The receiver thread currently only checks for wants_to_quit (and subsequently calls process::exit) whenever it prints a new colorized entry. If I remember correctly, this explicit check was necessary in order not to mess up the terminal with unclosed escape sequences. The uncolorized case (e.g. when piping to a file) does never check wants_to_quit. Note that the receiver shuts down when all senders have been closed.
• The sender threads check wants_to_quit whenever they receive a new file system entry. If wants_to_quit is set to true, the thread shuts down. Note that every sender thread needs to receive a new filesystem entry after Ctrl-C was pressed.

[sharkdp]

I'd like to close this ticket.

I tried many different things, but I can't reproduce this right now (although I have observed similar behavior in the past). Nevertheless, I have added a fallback mechanism in 2545aaa which should definitely exit fd when Ctrl-C is pressed a second time.

One option to reproduce the original problem would be to simulate a really slow filesystem, but I couldn't find a simple way to do this. If someone still observes this behavior, please let me know how to reproduce the issue.

[sharkdp]

The change mentioned in my last comment has been released in v7.4.0.