Thanks for taking a look at this! It looks like Windows stuff is failing because there's no static initializer for Window's version of rb_nativethread_lock_t (see thread_native.h for internals). You can make it file local and init in during Init_signal.

This mutex also needs to be reinitialized after a call to fork or else the child might hit a deadlock. In rb_thread_atfork_internal() you can add a rb_signal_atfork() and do it there.

@luke-gruber Thanks for the feedback! I will work on making these changes and update the PR.

@luke-gruber I've made the changes you've recommend:

• Initialized this mutex during signal setup so it’s ready before any handler queries happen.
• Provided a fork hook to reinitialize the lock after forking and invoked it from the thread fork path to prevent deadlocks in the child.
• Tests now pass on all platforms, including Windows.

Please let me know if you have any additional feedback.

I've made the allocation and initialization of sig_check_lock conditional on POSIX_SIGNAL and SIG_GET being defined. I've also changed the code to always define rb_signal_atfork, moving the conditions inside the function body.

Please let me know if I've gotten anything wrong and if you'd like me to make any other changes (e.g. squashing these changes into a single commit). Thanks so much for reviewing this code!

I guess some bespoke real-time OSes, stuff within the government (e.g. systems that control rocket ships), and very old mainframes that are still technically "alive", for some definition of that word, but just about everything else is POSIX or Windows.

Ah, sorry, I meant any of the platforms supported by ruby.