comment on

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

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 );

}
[download]

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

In reply to Re^11: Is there a problem with IPC::Open on Windows 7? by glasswalk3r
in thread Is there a problem with IPC::Open on Windows 7? by glasswalk3r

Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
Want more info? How to link or How to display code and escape characters are good places to start.


"be consistent"
	PerlMonks