Our current mechanism for accessing the C raise() function is broken on Windows if using the debug CRT

[njsmith]

We need to be able to deliver signals to the current process, both for testing, and to handle an obscure race condition in open_signal_receiver. On POSIX we just use os.kill, but on Windows we use the C raise function (since the kill syscall doesn't exist, and os.kill wrapper does something very different). We get access to it via cffi, loading the api-ms-win-crt-runtime-l1-1-0.dll.

But, it turns out that this is not always the correct DLL to use. In particular, if the Python interpreter is built against the debug version of the CRT, you have to use ucrtbased.dll instead.

Fortunately, this does not affect many people, because people rarely use debug interpreters. But, as far as I know there is no way to figure out which DLL is correct, so right now Trio just can't support debug interpreters on Windows :-(.

Relevant discussion:

• bpo-23057: Use 'raise' to emulate ctrl-c in proactor tests python/cpython#11274 (comment)
• https://bugs.python.org/issue35568

Possible solutions:

• Figure out a way to autodetect which CRT the interpreter is using?
• As suggested in bpo-35568, get the stdlib to add a wrapper for raise so that we don't have to go grovelling around in DLLs by hand?

[njsmith]

@eryksun suggested a clever trick to emulate a control-C in this comment, which I think would work fine for the testing use cases, but unfortunately it doesn't seem like the best way to re-deliver a signal when its handler has changed...

[A5rocks]

I think #3126 fixed this.