Ignore Ctrl-C about rust-ctrlc HOT 5 CLOSED

I think the most idiomatic way would be to change set_handler to take an Option<F> instead of F, that however would be backwards incompatible. If we want to preserve backwards compatibility, fn set_empty_handler() could do.

About the differences between operating systems, I would like to have the same behavior on all systems. I think if there's no way to make the behaviors between operating systems to be the same, it's better to leave the feature out.

from rust-ctrlc.

We are never going to achieve 100% the same behavior, considering the underling OS mechanisms we abstracting over are completely different. I feel like allowing for this small difference is perfectly acceptable.

On a Unix terminal, there is only one app in the foreground at a time, and only the foreground app will receive SIGINT signals. If you want the signals distributed to your children, you must do this manually. On windows the whole process group receives CTRL+C events. Considering that when you block CTRL+C you most likely don’t want it to kill your children, I feel like inheriting the block status makes sense.

from rust-ctrlc.

Putting it that way it indeed sounds reasonable. I would like to change the set_handler function and release a new major version for this, what do you think?

from rust-ctrlc.

Yeah sure, if you don’t want to wait and maybe implement some of my other suggestions. We should mention the inherence behavior in the docs.

from rust-ctrlc.

Yeah sorry, I read through the issues starting from the oldest one and had not read the other proposals before commenting. Implementing the other suggestions seems to be the right thing to do here.

from rust-ctrlc.