Exit the process a short time after entering our ctrl-c handler #125523
Conversation
rustbot
added
S-waiting-on-review
|
Thanks! @bors r+ |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#121377 (Stabilize `LazyCell` and `LazyLock`) - rust-lang#122986 (Fix c_char on AIX) - rust-lang#123803 (Fix `VecDeque::shrink_to` UB when `handle_alloc_error` unwinds.) - rust-lang#124080 (Some unstable changes to where opaque types get defined) - rust-lang#124667 (Stabilize `div_duration`) - rust-lang#125472 (tidy: validate LLVM component names in tests) - rust-lang#125523 (Exit the process a short time after entering our ctrl-c handler) r? `@ghost` `@rustbot` modify labels: rollup
| // of time exit the process. This sleep+exit ensures that even if nobody is checking | ||
| // CTRL_C_RECEIVED, the compiler exits reasonably promptly. | ||
| CTRL_C_RECEIVED.store(true, Ordering::Relaxed); | ||
| std::thread::sleep(Duration::from_millis(100)); |
There was a problem hiding this comment.
this has a change in behavior which I think may not be intentional: if the user hits Ctrl C twice, it will still wait 100 ms instead of exiting immediately
There was a problem hiding this comment.
It's intentional. You could definitely argue that it is bad, if you want.
I added the behavior of immediately exiting on the second ctrl-c because I thought it would be the obvious thing to try if the compiler didn't respond to the first. At least the most recent issue #125428 indicates this is either not obvious or prevented in some scenarios.
100 ms is a long time for a program, but significantly shorter than even an athlete's reaction time. Unless the OS scheduler truly hates us, the process should exit before the user even has time to realize the process didn't immediately exit and send a second ctrl-c.
Rollup merge of rust-lang#125523 - saethlin:ctrlc-timeout, r=bjorn3 Exit the process a short time after entering our ctrl-c handler Fixes rust-lang#124212 r? `@bjorn3`
Fixes #124212
r? @bjorn3