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

Re^8: Is there a problem with IPC::Open on Windows 7?

by BrowserUk (Pope)
on Aug 13, 2013 at 16:18 UTC ( #1049310=note: print w/ replies, xml ) Need Help??


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

Here is one implementation which I based mine: https://github.com/lucastheisen/ipc-open3-callback

Okay. That makes more sense than your original description -- though I see how you arrived at that description.

Essentially, they are doing the same thing as Win32::SocketPairopen2() and Win32::SocketPairopen2_5() (original author:salva), in that they are redirecting the outputs from the commands via socket pairs, which are selectable.

I'm like the idea of IPC::Open3::Callback. It is a very clever way to address both the problems with IPC::Open3.

However, as it stands, it steals both the pid of the subprocess, and the stdin; which make it less useful than it could be. I can see myself stealing the idea of the callbacks and producing my own version that corrects for those. (Assuming the author doesn't modify his interface before sending it to cpan :)


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.


Comment on Re^8: Is there a problem with IPC::Open on Windows 7?
Select or Download Code
Re^9: Is there a problem with IPC::Open on Windows 7?
by glasswalk3r (Pilgrim) on Aug 13, 2013 at 16:44 UTC

    I would suggest you to contact the author of IPC::Open3::Callback: he is already trying to upload the distribution into CPAN, maybe he would be open to accept your suggestions.

    I didn't get what do you mean by saying:

    However, as it stands, it steals both the pid of the subprocess, and the stdin; which make it less useful than it could be.

    It does has an method to retrieve the PID of the child process, something that is not available in IPC::Run and IPC::Cmd.

    Alceu Rodrigues de Freitas Junior
    ---------------------------------
    "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill
      It does has an method to retrieve the PID of the child process,

      Unless I'm looking at an out-of-date version, there is no pid method I can see.

      However, I just noticed it does have a sendInput() method. With the addition of a getPID method, that would probably address my desires.


      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.

        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:

        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:

        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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (11)
As of 2014-04-18 14:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (469 votes), past polls