Win32 Perl processes already have an asynchronous, interprocess, queuing mechanism. Its called the process queue.
It is how the few signals currently implemented are done. Its great advantage over any other mechanism is that the system already delivers some signals this way. ^C, ^Break, asynchronous timers, etc. It could be extended to emulate (some) other signals. A good first step would be to not convert all but four signals, (BREAK, INT, QUIT & TERM), sent to a process, into untrappable, fatal ones.
How far you could go with emulating signals is an open question. On *nix, many of them are raised by the system itself. For example, it would be possible to have another perl process signal its parent (SIGCHLD) when it terminates. But it's extremely difficult to arrange this for any non-perl child process.
It might be possible to inject code into the non-perl child process, but only if the required privileges are available. In many cases they would not be, which makes for a consistency problem. Even when the privileges are available, code injection is hard to get right for arbitrary processes. And, in many cases it could be seen as a security risk that opened the door to abuse.
In reply to Re: Implementing signals for Win32 Perl using named pipes
by BrowserUk
in thread Implementing signals for Win32 Perl using named pipes
by Corion
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |