Implement register and flag::register for Windows.

[qnighy]

This is another attempt at Windows support in #18.

Main differences from #18:

• pipe/iterator supports are postponed.
• Not using SetConsoleCtrlHandler directly. Instead, use signal/raise directly.
• We no longer have the __emulate_kill workaround. raise works.

As for #18, confirmed to catch Ctrl-C in some cases, but not all cases.

[vorner]

Thank you very much, I like it :-).

I never learned not to nitpick, so there are few suggestions about naming or comments. Nothing of any particular substance, though.

[vorner]

I'd suggest listing the consequences here ‒ „If this happens, the default handler is called instead“.

[qnighy]

signal() comes before RCU store -- so I guess nothing happens (neither the default handler nor the registered handler is called) instead.

[vorner]

I'm not sure I understand. Or, are we both thinking about the same race condition?

This is what I fear might happen:

• SIGTERM (or something else) arrives. This resets the signal to default, which is terminate.
• It calls the handler.
• Before the handler can re-establish itself back from the default, another SIGTERM arrives. This one terminates the program, because it didn't get re-established.

It is probably quite rare for the user to press CTRL+C that fast, so it most probably won't happen, but in theory something could send them programmatically?

But I'm not sure about the theory.

[qnighy]

Yeah I imagined a different one than yours, so I added another bullet here to describe yours. The one in my mind was:

• The program tries to register a handler for SIGINT. It acquires the RCU lock. We don't block signals here because there's no such machinery in Windows.
• signal is called. Our global handler function is registered.
• SIGINT arrives. As handler is already registered, the default handler isn't invoked. However, we haven't stored the RCU result yet so there's no shared handler registered.
• RCU store happens.

In this case we miss SIGINT where we expect the default handler ("before handler registration" case) or the registered handler ("after handler registration" case) to be invoked.

[vorner]

Getting there :-). There are these little details I'm not sure about I'd like you to have a look at, but if you think I'm wrong, it'd be fine to merge it as it is.

I'm thinking about one other thing. This sub-crate is already 1.0. Adding new functions is fine, but that means promising not to ever remove or change their signatures. I'll probably ask around a bit, if there's a convention how to get an unstable part of API in otherwise stable crate ‒ so maybe I'll hold releasing it a bit after it gets merged, to be on the safe side. I hope it's not a problem. If you have a suggestion how to solve this, I'd be interested in hearing it.

[vorner]

Thank you. I'll mark the new functions/the ones that have different signature in some way to clearly state they may still change a bit and will release the registry crate over the weekend.

[vorner]

Looking through the newly introduced API, there seems to be nearly nothing (only the register_signal_unchecked function), so I think it's fine to promise API stability on this.

Do you want to add yourself to the crate authors, before I release?

[qnighy]

Do you want to add yourself to the crate authors, before I release?

Yes, I'll prepare a PR in minutes...