Include signal.h for sig_atomic_t in WIN32 #8112

We need to include signal.h in WIN32 to get a definition for sig_atomic_t since #8004.

Perhaps this is only necessary on MinGW, and not on native Windows, but I don't know how to test for that.

Does anyone know what was the rationale to not include signal.h on WIN32 before? Does this break native windows builds?

This commit that was part of removing headers.h, moved signal.h into a WIN32 ifndef in main.cpp, but that doesn't have any specific reasoning.

If this does break native windows builds, we should do this differently: define our own type, which is a typedef of sig_atomic_t on UNIX-ish OSes, and volatile int or such on Windows, as there are no signals on that OS anyhow.

Or could we simply use an c++11 atomic here? Is there something special about sig_atomic_t with signals?

On Windows, do we even install signal handlers?

No (windows uses a different signalling mechanism based on messages) See also https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L785

Then perhaps we should not declare that variable as sig_atomic_t at all on Windows., as it won't be used for its intended purpose anyway.

That's what I suggested above: define our own type for it, which is sig_atomic_t only on UNIXish OSes but something else on windows. I still think it should be atomic because at least fRequestShutdown is used to communicate between threads.

Which means maybe we should simply use a c++11 atomic there, which are available without problems on both Windows and Linux?

@laanwj I think that's the way to go; see #8123.

Closing in favor of #8123