Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

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

by Theory (Beadle)
on May 13, 2012 at 22:26 UTC ( #970350=note: print w/ replies, xml ) Need Help??


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

Good to know, thanks. Perhaps I should report it as a bug to p5p.

But I could not see anywhere where it does something with $SIG{PIPE}. I assume that is something I would still have to do myself. I do not want to. I want errors form the child to simply be thrown as exceptions. Is $SIG{PIPE} the only error handler that needs to be installed? And there is no way to lexically scope it, either.

What I'm thinking of now is some sort of OO interface, call it IPC::Simple, where you instantiate by passing it the command, it does all of the IPC error handling for you, turning stuff into exceptions (not unlike IPC::System::Simple does for system and backticks), and accessors for the STDIN, STDOUT, and STDERR file handles. I Just need STDIN for my current app, but I think a more generally useful Open3-based solution that properly scopes IPC error handling to throw exceptions would be very useful. IPC::Pipe is close-ish, but does not do the error handling stuff, I looks like. AMIRITE?


Comment on Re^2: What is the preferred cross-platform IPC module?
Select or Download Code
Re^3: What is the preferred cross-platform IPC module?
by BrowserUk (Pope) on May 13, 2012 at 22:45 UTC
    But I could not see anywhere where it does something with $SIG{PIPE}.

    Windows doesn't do signals. Perl emulates a few for compatibility, but sigpipe isn't one of them.

    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.

    As such, I believe that it is better to move the platform dependency out of the IPC module to the level above, and call a platform specific subroutine to perform the IPC.


    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?

      Sure, if you know what platform your app will run on. But it's no help for, say, a cross-platform CPAN library.

      Good to know $SIG{PIPE} isn't emulated on Windows. Makes me feel, though, like there is no point in worrying about errors, and I should just assume that everything will work. Annoying, though.

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

          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?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://970350]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (10)
As of 2014-09-18 07:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (109 votes), past polls