Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow passing through the 2nd ctrl+c #46

Closed
kpcyrd opened this issue Sep 23, 2018 · 1 comment
Closed

Allow passing through the 2nd ctrl+c #46

kpcyrd opened this issue Sep 23, 2018 · 1 comment

Comments

@kpcyrd
Copy link
Contributor

kpcyrd commented Sep 23, 2018

I'm considering adding a ctrl+c handler, but since I'm only setting a bool it might take a while until my program is actually picking it up. The application would feel broken since it can not be terminated in a reliable way even after pressing ctrl+c multiple times. I'm thinking about 2 possible solutions:

  • inside the signal handler, allow passing through the signal so if ctrl+c is pressed, I would first check the value of the boolean, if it is true I set it to false, if it is false, I let the signal pass and terminate the process
  • allow removing the signal handler. Before I start an action that should be cancelable, I register a signal handler and if ctrl+c is pressed I'm setting the boolean to false and unregister the signal handler so that the second ctrl+c isn't caught anymore (Related to allow to reset the ctrlc handler #24)

Basically I'm looking for behavior similar to this (implementation doesn't need to be identical as long as the behavior is the same):

from time import sleep
try:
    try:
        print('running...')
        sleep(20)
    except KeyboardInterrupt:
        # requesting shutdown
        print('exiting...')
        sleep(5)
except KeyboardInterrupt:
    # kill application instantly
    pass
@Detegr
Copy link
Owner

Detegr commented Sep 24, 2018

Can you just kill the process yourself from your handler when entering the handler a second time?
Something like this results in a similar behaviour than your python example:

extern crate ctrlc;
use std::process;
use std::sync::atomic::{AtomicUsize, Ordering};
use std::sync::Arc;
use std::thread;
use std::time::Duration;

fn main() {
    let running = Arc::new(AtomicUsize::new(0));
    let r = running.clone();
    ctrlc::set_handler(move || {
        let prev = r.fetch_add(1, Ordering::SeqCst);
        if prev == 0 {
            println!("Exiting...");
        } else {
            process::exit(0);
        }
    }).expect("Error setting Ctrl-C handler");
    println!("Running...");
    for _ in 1..6 {
        thread::sleep(Duration::from_secs(5));
        if running.load(Ordering::SeqCst) > 0 {
            break;
        }
    }
}

@Detegr Detegr closed this as completed in badc310 Apr 23, 2019
leod pushed a commit to leod/rust-ctrlc that referenced this issue Jun 3, 2023
- Upgraded nix dependency
- Removed deprecated usages of ATOMIC_BOOL_INIT
- Removed contributors from authors field
- Formatted with latest rustfmt
- Fixes Detegr#46 by including an example
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants