in reply to Re^10: Is there a problem with IPC::Open on Windows 7?
in thread Is there a problem with IPC::Open on Windows 7?

You're correct, there is none. It shouldn't be that hard to implement it by creating a related attribute and setting it in the runCommand method call. Since I already have one implemented in Siebel::Srvrmgr::Daemon and I really need to have complete control, I'm not considering IPC::Open3::Callback right now (but it would be worth checking it again later).

During additional tests yesterday, I was able to run Siebel::Srvrmgr::Daemon several times without problem in Linux and being able to read STDERR as well. Unfortunately, I got the same error (ECONNRESET) that I was getting in Windows 7 when I repeated the test today:

ok 49 - run method executes successfuly ok 50 - shift_command works ok 51 - The object isa Siebel::Srvrmgr::Daemon::Command ok 52 - shift_command works ok 53 - shift_command works ok 54 - run method executes successfuly (2) ok 55 - run method executes successfuly (3) not ok 56 - run method fail due timeout # TODO Usage of alarm must be +reviewed # Failed (TODO) test 'run method fail due timeout' # at t/Test/Siebel/Srvrmgr/Daemon.pm line 207. # (in Test::Siebel::Srvrmgr::Daemon->runs_blocked) sysread() on unopened filehandle 1 at .\lib/Siebel/Srvrmgr/Daemon.pm l +ine 1364. not ok 57 - runs_with_stderr died (sysreading from 11 returned an unre +coverable error at .\lib/Siebel/Srvrmgr/Daemon.pm line 847) # Failed test 'runs_with_stderr died (sysreading from 11 returned an + unrecoverable error at .\lib/Siebel/Srvrmgr/Daemon.pm line 847)' # at .\t\Daemon.t line 4. # (in Test::Siebel::Srvrmgr::Daemon->runs_with_stderr) ok 58 # skip runs_with_stderr died ok 59 # skip runs_with_stderr died ok 60 # skip runs_with_stderr died # Looks like you failed 1 test of 60.

Researching the error in Google, I found this http://stackoverflow.com/questions/16675950/perl-select-returning-undef-on-sysread-when-using-windows-ipcopen3-and-ios, which led me to disable using shutdown in the sockets when running in Windows. It worked, but I'm not sure why besides this explanation in the documentation:

It's also a more insistent form of close because it also disables the file descriptor in any forked copies in other processes.

Since select and Scalar::Util openhandle tells me that the handles are OK for reading/writing, I clueless why this error happens. It seems to be related to some inactivity with the child process because if I keep calling run method sequentially, everything keeps working as expected. If I "wait" a bit, the error happens.

This is the modified version of mswin_pipe that seems to be working as expected:

sub _mswin_pipe { my ( $read, $write ) = IO::Socket->socketpair( AF_UNIX, SOCK_STREAM, PF_UNSPEC ); # :WORKAROUND:14/08/2013 14:15:04:: shutdown the socket seems to disab +le the filehandle in Windows unless ( $Config{osname} eq 'MSWin32' ) { Siebel::Srvrmgr::IPC::_check_shutdown( 'read', $read->shutdown(SHUT_WR) ); # No more writing for reade +r Siebel::Srvrmgr::IPC::_check_shutdown( 'write', $write->shutdown(SHUT_RD) ); # No more reading for writ +er } return ( $read, $write ); }

I believe this needs more testing. I'll repeat the tests by forking a different program and see what happens in Windows. It would make sense to set SO_KEEPALIVE to the sockets/handles?

Alceu Rodrigues de Freitas Junior
---------------------------------
"You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill

Replies are listed 'Best First'.
Re^12: Is there a problem with IPC::Open on Windows 7?
by BrowserUk (Patriarch) on Aug 14, 2013 at 18:27 UTC
    sub _mswin_pipe { my ( $read, $write ) = IO::Socket->socketpair( AF_UNIX, SOCK_STREAM, PF_UNSPEC );

    Are you running this code directly under windows or via some *nix emulation layer (eg.cygwin)?

    Because I've never seen sockets in the AF_UNIX domain created under windows.


    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.

      Nowadays I'm running this code in Linux and Windows 7, so no emulation here. :-)

      I still trying to understand this trick of using sockets instead of filehandles in Windows to be able to do select without blocking. It seems it solves the problem of blocking, but now I'm having other types of problem. Meanwhile, I will try to answer your question by quoting the same book that is helping me out (Network Programming with Perl from Lincoln D. Stein):

      • about Socket's domain, page 63
      • AF_UNIX is used for interprocess communication within a single host. The name AF_UNIX is unfairly UNIX-specific; it's possible for non-UNIX systems to implement it. For this reason, POSIX has tried to rename this constant AF_LOCAL, although few systems have followed suit.
      • About socketpair, page 101:
      • While in principle socketpair can be used for INET protocol, in practice most systems only support socketpair for creating UNIX-domain sockets.

      Of course, I didn't know about those details before researching. As I said before, I just copied the related code and tried to adapt it to my needs.

      End of story: after disabling shutdown, the application (srvrmgr.exe) that I'm executing with open3 started behaving correctly (can be reused several times), but waitpid is not being able to kill it later: it was necessary to invoke kill 9 to do the job.

      Strange as it seems, running a external process as the Perl script that is shipped with Siebel::Srvrmgr works fine with waitpid in Windows and Linux.

      I had updated the SVN repository if you want to take a look.

      Alceu Rodrigues de Freitas Junior
      ---------------------------------
      "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill

        Further, the WinSock2 docs make no mention of AF_UNIX.

        And my attempt to use it compiles clean, but results in a runtime error (as expected):

        #include <winsock2.h> #include <ws2tcpip.h> #include <stdio.h> int main( int argc, char **argv ) { WSADATA wsaData = {0}; int iResult = 0; SOCKET sock = INVALID_SOCKET; if( WSAStartup(MAKEWORD(2, 2), &wsaData) != 0 ) { printf( "WSAStartup failed: %d\n", iResult); return 1; } sock = socket( AF_UNIX, SOCK_DGRAM, IPPROTO_TCP ); if( sock == INVALID_SOCKET ) printf( "socket function failed with error = %d\n", WSAGetLast +Error() ); else { printf( "socket function succeeded\n" ); iResult = closesocket( sock ); if( iResult == SOCKET_ERROR ) { printf( "closesocket failed with error = %d\n", WSAGetLast +Error() ); WSACleanup(); return 1; } } WSACleanup(); return 0; }

        Compile/link/run/error:

        C:\test>cl /W3 unixDomainSockets.c Ws2_32.lib Microsoft (R) C/C++ Optimizing Compiler Version 15.00.21022.08 for x64 Copyright (C) Microsoft Corporation. All rights reserved. unixDomainSockets.c Microsoft (R) Incremental Linker Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. /out:unixDomainSockets.exe unixDomainSockets.obj Ws2_32.lib C:\test>unixDomainSockets.exe socket function failed with error = 10047 C:\test>perl -E"say $^E=10047" An address incompatible with the requested protocol was used

        So, quite how you are getting away with using *nix domain sockets on Windows I have no idea; but I think that it is more by luck than judgement and probably not doing what you think it is.


        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 name AF_UNIX is unfairly UNIX-specific; it's possible for non-UNIX systems to implement it.

        Possible yes, but have MS actually done so? If so, when?

        Hm. I know I tried this years ago and got the same result as this guy.

        And the scant and unhelpful results I get from searching MS for AF_UNIX doesn't clarify anything. It appears in the header files, but there are no examples and no discussion of using it.

        When I get time and motivation I'll dip into C and play, see what I find.

        At this point I have no experience or knowledge of this to offer you.


        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.