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?
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
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |