Re^6: What is the preferred cross-platform IPC module?

C Std Lib pulls it off.

Really? Can you use select on an win32 pipe? Or stdin?
If perl used native file handles instead of MS CRT file handles, and make select Perl function map to WaitForMultipleObjects, then yes, http://msdn.microsoft.com/en-us/library/windows/desktop/aa365603%28v=vs.85%29.aspx. I think the reason why perl uses MS win32 select instead of WFMO was that 12-15 years ago when perl win32 was being developed, DOS Windows was the target platform. On DOS Windows, socket handles are not kernel/file handles, and can not be given to WFMO, on DOS Windows socket handles had to be given to WSAWaitForMultipleEvents. Sockets on DOS Windows were a 3rd party add on architecture wise and there used to be competitors to MS Sockets http://en.wikipedia.org/wiki/Winsock#Other_implementations. Interix and Cygwin pull it off.

That's like saying that a campervan pulls off being a house.
Cygwin was always a dog; and never got beyond POSIX 1 as far as I can tell.
Interix was deliberately ham-strung from the moment MS purchased it. They didnt want it to become a viable alternative development environment for windows. They offered and supported it only as a stop-gap to transitioning *nix software suits to the Windows Server environment. It will not ship with Windows 8.

Windows NT is POSIX certified from day 1, 1993, although you are correct MS is removing it for Windows 8, and it was put in to Embrace, extend and extinguish. Even though the formal POSIX api is going away, nothing prevents you from writing a POSIX API layer on Windows. The Linux kernel isn't 100% POSIX compatible without its usermode libraries anyway, http://www.kernel.org/doc/man-pages/online/pages/man7/aio.7.html http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library.
Signals on Windows are called Alertable IO. "

That is so wrong it defies refutation beyond this link.
MS Alertable IO has exactly zero to do with "POSIX signals"!
"Safe" signals on Win32 Perl are Windows Messages on the message queue,

Windows doesn't do POSIX signals.

Windows Alertable IO/APCs are an improved implementation of unix signals see http://books.google.com/books?id=xX5tfrAQQ8cC&lpg=RA1-PA79&vq=unix%20signal%20mechanism&dq=apc%20unix%20signal%20windows%20kernel&pg=PA188#v=snippet&q=unix%20signal%20mechanism&f=false and http://www.flounder.com/asynchexplorer.htm#Callback%20I/O.
non-safe signals (CRT Ctrl C and exit) usually will crash the perl interp since they actually run from another thread.

That is about as far from the truth as it is possible to get.
Perl uses the SetConsoleCtrlHandler() function to allow it to handle the various console events.

Your absolutely wrong. If your claiming thats not true, then this wouldn't crash for you or anyone else "Free to wrong pool" error..
*nix IPC revolves around: a) fork & exec; b) signals; c) selectable, non-blocking IO; d) pipes; e) Unix domain sockets.
Windows has its own IPC mechanisms: a) Clipboard; b) COM; c) Data Copy; d) DDE; e) File Mapping; f) Mailslots; g) Pipes (Anon;Named;stream;message); h) RPC; i) Windows Sockets.
Each of those is a wrapper around an APC or more often an Event Objects http://msdn.microsoft.com/en-us/library/windows/hardware/ff553350%28v=vs.85%29.aspx kernel wise. Even where the names on the different platforms are superficially similar; the implementation details are sufficiently different to make writing a common interface necessarily a lowest-common-denominator-via-crude-incomplete-emulation exercise that benefits no one.

So what are Cygwin, WINE, KernelEx, and Reactos?

No. My opinion is that they are much more efficient than a VM.

Comment on Re^6: What is the preferred cross-platform IPC module?

Replies are listed 'Best First'.
Re^7: What is the preferred cross-platform IPC module? by BrowserUk (Patriarch) on May 15, 2012 at 10:38 UTC
This deserves more attention than I gave it; either at the time or when you referenced it above: "Free to wrong pool" error.. This appears to be very similar in nature to the very first question that patcat88 first asked here. It is also related to this question, which after working with the OP for a long time, we did succeed in finding a resolution. There is also some related discussion in the PerlXS POD under the heading Safely Storing Static Data in XS. Getting back to the link you posted, the discussion there suggests that the callback that the core provides to `SetConsoleCtrlHandler()` isn't correctly handling the PerlInterpreter/Perl_Context issue. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' 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. The start of some sanity?	[reply] [d/l]
Re^7: What is the preferred cross-platform IPC module? by BrowserUk (Patriarch) on May 14, 2012 at 22:06 UTC
If perl used native file handles instead of MS CRT file handles, ... It doesn't so the speculation is moot. And in any case, that idea directly contradicts your own assertion that C Std Lib pulls it off. And think through the knock-on effects of that idea. What would Perl on nix use? It only has CRT filehandles. Finally, my assertion was made in the context of a discussion about non-core IPC modules, not re-writing the entire Perl core. Windows Alertable IO/APCs are an improved implementation of unix signals* I absolutely agree that POSIX signals are a fundamentally flawed concept & that Asynchronous IO is a far better approach... But seriously, suggesting the latter is a "better implementation" of the former is like suggesting that hydraulically operated anti-lock brakes with carbon-fibre pads and ceramic disks are a "better implementation" of jamming a stick in the wheel spokes. Although the goals are similar, it's more 'a completely different approach to solving the problem' than a "better implementation". Your absolutely wrong. If your claiming thats not true, All that just goes to prove the futility of trying to emulate one operating systems behavior within another. More grist to my mill that emulators are a waste of programmer effort in a world that has hardware assisted VMs; and further refutation of this: No. My opinion is that they are much more efficient than a VM. Upon which we will simply have to agree to differ. Emulators are always bug-ridden; always out-of-date; and always slow. I can see no point at all in using them. On my previous machine -- a lowly, single core P4 system -- I had Ubuntu running in a VirtualBox VM and could run Linux consoles (almost) transparently on my XP desktop. I then went a step further and ran XP inside a VM inside the XP hosted Ubuntu VM. I wouldn't recommend the latter, but I can see no reason to run buggy, out-of-date emulations when you can run the real thing in a VM. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' 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. The start of some sanity?	[reply]