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.
Then you dont have "signals" at all. die "signals not implemented";
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?
Evolving? IMO Perl 5 doesn't evolve. Many people with decision making power see Perl 5 as being in "maintenance mode" for legacy code, and back-compat is above all else.
What are safe signals? That is a term that Perl 5 created to mean a queue and deferred execution of signals at safe points. It isn't an OS feature. Non-blocking and async IO support in the core language is hit or miss on all the different platforms that Perl runs on. On Win32 Perl, sockets are the only non-synchronous IO. I've never seen any evidence of anyone using the native Win32 API (XS) in Perl for non-synchronous IO except me. The XS code for GUI toolkits on Perl sometimes disable (Glib
) with a comment in the code saying to use "native" Perl IO instead. In other cases the toolkits (QT) do blocking IO in an fresh OS thread, which is incompatible with Perl's architecture since OS specific non-syncronous IO is so hit or miss that the toolkit authors gave on it. Or, its not implemented in the toolkit on windows, Perl Tk
. Or not implemented at all, (WX).
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.
Perl 6 is not Perl 5, and never claimed to be syntax compatible. Is C# the successor of C++? Your piped open will block on windows when there is no data from the child process in the pipe.