On perl5-porters Nicholas Clark had the devious idea of implementing SA_SIGINFO on unixish Perls through a pipe. I'm a fan of devious ideas and I see some potential in this for Windows too.

The idea of SA_SIGINFO is, as far as I understand it, to send not only a signal from the outside to a process but also to include some more information to it (like, the filename to which to dump information etc). The problem, as always with signals is, that they come at times when it's not prudent for perl to handle them right away, so Perl needs to stash the signal and the additional information away until it is ready to handle the event. Nick's idea now is to create a pipe, write the information to the pipe when the signal arrives and once Perl is ready again to handle the signal in Perl code (PERL_ASYNC_CHECK()), to read the information back from that pipe.

On Windows, Perl basically does not support signals at all, because Windows has no signals.

It occurred to me that Perl could use named pipes on Windows to implement signals (from the outside world, or at least, other Perl processes) as well. Here is how I envision that could be done:

In principle on Win32, a named pipe is just a file with the (magic) name \\.\pipe\$name, so Perl could (upon request?) create a pipe \\.\pipe\Perl\$pid. For sending a message/signal to the process, you just copy the content to said pipe and for receiving a message from it, you just read from that pipe, in an atomic fashion of course. Perl processes could handle sending signals through magic in kill etc. and other processes can just write to the pipe if they know the proper format.

All the Win32 API is already there, even in Perl (CreateFile() and CreateNamedPipe()), but what I'm missing for this crazy idea I have no time to implement is a way to get (Perl code to run) at PERL_ASYNC_CHECK(). I presume that having a Perl handler for PERL_ASYNC_CHECK() is not possible, as PERL_ASYNC_CHECK() is part of the runloop and Perl prefers not to reenter the interpreter while it is doing housekeeping.

On the third hand, I'm not sure whether having signals is really something people want on Win32 - I haven't felt the need for it at all. The unix-like usage of signals would be limited to other Perl processes anyway due to the special signal implementation. But sending a signal to any Perl process could then also be done by COPY CON: \\.\pipe\Perl\42 from the command line or any process, provided that the format written to that "file" is something Perl will recognize.

As the crazy second stage, this could be used as the central entrypoint+queue for all things asynchronous, like asynchronous file IO and window messages, provided we are content with the idea of stuffing all this into a named pipe which will eventually get full.

Basically, I'm looking for Perl internals wisdom and Win32 wisdom to get a better roadmap of where the big roadblocks for this idea lie.