http://www.perlmonks.org?node_id=970447


in reply to Re^3: What is the preferred cross-platform IPC module?
in thread What is the preferred cross-platform IPC module?

IMO, Windows and *nix/POSIX IPC are just too different to successfully wrap them over in a common interface. I've not found a single 'portable' module that works well on Windows.

I disagree. C Std Lib pulls it off. Interix and Cygwin pull it off. Signals on Windows are called Alertable IO. "Safe" signals on Win32 Perl are Windows Messages on the message queue, non-safe signals (CRT Ctrl C and exit) usually will crash the perl interp since they actually run from another thread. On the other land, if you what you mean by "common interface" means "compile and go api compatibility", then no. Regarding POSIX-ish modules working on windows, unless they wrap an external library which already does windows, I agree, there are very few outside the Win32::* namespace that have windows specific code.
  • Comment on Re^4: What is the preferred cross-platform IPC module?

Replies are listed 'Best First'.
Re^5: What is the preferred cross-platform IPC module?
by BrowserUk (Patriarch) on May 14, 2012 at 16:24 UTC
    I disagree

    You are entitled to your opinion, but nothing in the rest of your post suggests that opinion has any merit.

    C Std Lib pulls it off.

    Really? Can you use select on an win32 pipe? Or stdin? 

    use IO::Select;;
IO::Select->new( STDOUT ) or die $^E;;
@s = $s->can_read() or print "$^E";;
An operation was attempted on something that is not a socket

    [download]
    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.

    If you want to develop in a *nix environment; install one of the billion free distributions. If you need to run a mixed environment, use an VM. It simply makes no sense to use a POSIX-1 emulator.

    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.

    "Safe signals": a) are purely a Perl concept; b) apply to Perl on *nix just as much as they do on Windows; c) the "safe" bit simply applies to when signals are responded to by the Perl interpreter, not how they are implemented.

    The message queue is used to by Perl to implement its emulation of signals on Windows.

    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.

    Take a close look at Perl_sys_intern_init() & win32_ctrlhandler() in Win32.c for the details of how Perl emulates POSIX signal handling for a limited number of signals.

    The signals emulated include INT, QUIT, TERM, and BREAK which are all trappable. All others non-trappable and cause the process to be terminated, cleanly via TerminateProcess().

    1. Perl doesn't "crash" when it receives ^C.

      If you've installed a SIGINT handler. then it gets control:

      C:\test>p1
[0] Perl> $SIG{INT} = sub{ print "Got ^C" };;
[0] Perl> Got ^C
Got ^C
;;
[0] Perl>

      [download]

      If you haven't, the processes is cleanly terminated.

    if you what you mean by "common interface" means "compile and go api compatibility", then no.

    What I mean, is exactly what I said: IMO, Windows and *nix/POSIX IPC are just too different to successfully wrap them over in a common interface.

    *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.

    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.

    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]
[select]
[reply]
[reply]

        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]
        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]

In Section Seekers of Perl Wisdom