Wow, that's *seriously* deep stuff, you've attempted! I don't think I want to go that deeply into the forest. The quote, "Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup" would seem to apply to me regarding the things you tried. Your paragraph beginning with "I did once take a C debugger, . . .," made me smile because it sounded like the beginning of one of the stories an Arthurian knight might have spun. Powerful stuff, nonetheless.
The next paragraph about the dispatch of events from perked my interest because I can see how that could work to solve the issues you raised in the first paragraph. I'm going to return to that first paragraph because I think it's the most interesting of all.
Thank you for the advice about the p5p mailing list. I've come to the conclusion that I need to craft my own console control handler in XS and install it on top of Perl's, ensure that it works to my satisfaction, and then I'll be able to make a more acceptable contribution. It sounds like they may be a great source of wisdom in that endeavor. And tracking the evolution of win32.c actually sounds like fun! So I know I'll do that. Thank you, again.
Now back to that first paragraph (written with a smile)! You wrote:
How do you ensure the responsiveness of the fake-signal if the main thread is blocked in the kernel?
One possible answer might be, "you don't." Your other question holds the key to that idea.
The problem with just "sending" a message to the main thread is, what if the main thread is in a blocking syscall, directly from Perl lang or through some XS-ed C library?
Isn't Perl5 evolving in that direction, anyway? Aren't those restrictions similar to the limitations of "safe signals"? Are there many things that can *only* be done via blocking syscalls in the main process? It reminds me of the classic "doctor-patient joke:"
Doctor: Please tell me about your problem.
In Perl5 we have many tools to allow the use of multiple processes (in Windows, Linux, and the other platforms as well) to handle the types of things most people would want to use blocking syscalls for anyway. With simple IPC techniques like piped opens and "safe signals" why bother with complex, flawed, and potentially crash prone things like full POSIX signals anyway? I can see that you have the skills and moxie to attack that problem, but I can't help but wonder whether or not the better way is simply to accept Perl5 as a wonderful single-threaded C program (perhaps the greatest, ever) and maybe leave those more complex issues to the Perl6 people.