Problems? Is your data what you think it is? | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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:
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.
In reply to Re^3: Implementing signals for Win32 Perl using named pipes
by BrowserUk
|
|