Antti Keränen

I see there are two crates in crates.io doing async implementation over `ctrlc`: - [async-ctrlc](https://crates.io/crates/async-ctrlc) which is a wrapper over `ctrlc`. - [ctrlc-async](https://crates.io/crates/ctrlc-async) which is, if I'm not mistaken, this...

There are better signal handler libraries in the Rust ecosystem nowadays. I'm keeping `ctrlc` the simple wrapper it has always been.

Closed as stale.

I think `resolver = "2"` in Cargo.toml fixes this issue nowadays.

No one seems to be interested enough in reviewing my code in the pull request, which is completely understandable. It's been multiple years now so I'm thinking the counter+channel code...

I'd like to see this feature implemented in a way where the user would set the handler with a builder of some sort that had an option to not inherit...

If I understand correctly, in `juliaup` you would set signal handlers back to default, launch the child process and then set the signal handlers back, am I right? The issue...

The handle object approach would not work with child processes though as they inherit the signal handlers (on *nix). Now that I'm reading this discussion again I'm starting to think...

Sounds like a powershell problem to me if it works with older versions but does not work with recent ones.

Could be done in a new major version.