Re^2: Implementing signals for Win32 Perl using named pipes

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")
[download]

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 :).

Comment on Re^2: Implementing signals for Win32 Perl using named pipes Select or Download Code

Replies are listed 'Best First'.
Re^3: Implementing signals for Win32 Perl using named pipes by BrowserUk (Patriarch) on Mar 11, 2008 at 11:13 UTC
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); } [download] 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l] [select]
Re^4: Implementing signals for Win32 Perl using named pipes by Corion (Patriarch) on Mar 11, 2008 at 11:50 UTC
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; };` [download] which basically gives you a detachable console to any Perl process.	[reply] [d/l]


Just another Perl shrine
	PerlMonks