Add `revert_to_default()` or similar about rust-ctrlc HOT 6 OPEN

I'm also looking for the ability to remove a ctrlc handler. In my case I'm interested in building a CLI interaction library (think readline) that ought to handle ctrl-c internally, but then should return things to their original state when handing back control to the user.

It seems logical to me that ctrlc::set_handler return a "handle object" that, when dropped, removes the signal handler.

from rust-ctrlc.

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 the signal handlers for a child processes. However in practice I think this is very tricky, if not impossible.

Could you have a wrapper executable in juliaup that would (re)set the handlers to SIG_DFL using libc or nix crates and then launch the child process?

from rust-ctrlc.

Could you have a wrapper executable in juliaup that would (re)set the handlers to SIG_DFL using libc or nix crates and then launch the child process?

Yes, juliaup is that wrapper executable. We can of course manually use libc crates to undo what ctrlc has done, but I believe that if ctrlc contains functionality to set default signal handling for a signal, it makes sense for ctrlc to also provide functionality to reset signal handling back to the default, otherwise if ctrlc changes something about how it performs its signal overloading, we may need to adjust our resetting in the future. I'd rather not have code in the higher context (juliaup) that is so intimately coupled with the implementation details of ctrlc.

from rust-ctrlc.

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 I see with that approach is that it would result in code where a SIGINT could kill the program if it hits the part of the code that had the signal handlers reverted back to default. To safely handle this I think you'd need to launch a wrapper subprocess first that reverts its signal handlers and then launches the actual subprocess, that way the main juliaup binary would always be able to handle its signals correctly.

Now that I wrote it out, I realized it may still be beneficial to have the feature as you could use it in the wrapper child process to revert the handlers, should you decide to implement it that way.

from rust-ctrlc.

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?

Not quite, we start up the signal handlers as soon as the child process launches (ignoring CTRL-C in the launcher so that the child process can receive it correctly), but then after the child process exits, we want to set the signal handlers back to default. This is because if the child process gets killed due to SIGINT, we want to be able to then kill ourselves with a SIGINT and have someone who is waiting on the wrapper process to be able to determine that this is why the underlying process exited. Specifically, we raise() the signal that the child process died due to, but this raise() is ineffective without having some way to undo what the ctrlc crate does.

from rust-ctrlc.