Thanks - this is just the information on Windows that I hoped to get from Perlmonks! I wasn't aware that Windows has a process (message) queue. So far, I was under the impression that for a message queue you always needed a window handle.
As for sending "signals" from non-Perl processes, I think this is a lesser priority, because any non-Perl process can always use the moral equivalent of
system('perl','-e',"kill SIGWHATEVER => $pid")
to send a signal to a Perl process. I think code injection is an interesting toy but far too unreliable/difficult if you want to use IPC. If the easier alternative is shared files, code injection does not look good :). | [reply]
[d/l]
[select] |
I wasn't aware that Windows has a process (message) queue. So far, I was under the impression that for a message queue you always needed a window handle.
Um. I get a little fuzzy with my terminology. Threads can(*) have message queues, not processes. Of course, in a single threaded process, the two are (roughly) equivalent.
(*)From PostThreadMessage(): "The system creates a thread's message queue when the thread makes its first call to one of the User or GDI functions.".
In Perl, this (probably) occurs when Win32_create_message_window() is called:
## win32.c
HWND
win32_create_message_window()
{
/* "message-only" windows have been implemented in Windows 2000 an
+d later.
* On earlier versions we'll continue to post messages to a specif
+ic
* thread and use hwnd==NULL. This is brittle when either an embe
+dding
* application or an XS module is also posting messages to hwnd=NU
+LL
* because once removed from the queue they cannot be delivered to
+ the
* "right" place with DispatchMessage() anymore, as there is no Wi
+ndowProc
* if there is no window handle.
*/
if (!IsWin2000())
return NULL;
return CreateWindow("Static", "", 0, 0, 0, 0, 0, HWND_MESSAGE, 0,
+0, NULL);
}
See also win32_kill() in the same file.
If you use the fork emulation, to start a non-perl, child process, then a thread is spawned to act as a 'placeholder' for the actual process. This then waits for the alien process to terminate and so can (could?) post (raise) a SIGCHLD to the main or spawning thread. The problem is that signals sent to the child pseudo-process' pseudo-pid do not necessarially reflect the state of, or affect, the real alien process. And that's where the emulation falls down.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
For the (imagined) central problem of sending an asynchronous message from outside the Perl process to the running Perl program, I think this emulation is sufficient. This at least brings the possibility to have some form of asynchronous communication between two Perl processes on Windows in a similar fashion as Unix.
Also, I imagine a fun application of SA_SIGINFO could be a hook like this:
$SIG{SIGINFO} = sub {
my ($info) = @_;
eval $info;
};
which basically gives you a detachable console to any Perl process. | [reply]
[d/l] |
BREAK, CTRL-C, QUIT can be handled using a Control Handler. You can setup a handler function using the Win32 API SetConsoleCtrlHandler() and raise one of these "signals" using GenerateConsoleCtrlEvent().
When a new process is created on Windows it can inherit the console of the parent, but this can be hidden (SW_HIDE). That way it is possible to emulate sending a signal to a "process group".
Using a named pipe has its advantages, but would also need to be linked to exception handling as well, C0000005 generate a SIGSEGV? Emulating a SIGCHLD would be difficult, since there is no way to identify your parent, unless its PID is passed explicitly.
I agree with the comments on injection, but if anyone wants to pursue that one I have some code which uses that technique in Win32::EnvProcess. | [reply] |
