in reply to Re^6: Forking Clients
in thread Forking Clients

Does this explain it better?

Kinda. Ignoring how it is implemented for now, let's assume that your functions blah() & blee() etc. are written so that they support the following api:

my $blah = blah( ... ); my $blee = blee( ... ); ... if( $blah ) { my @blahResults = $blah->(); ... } ... if( $blee ) { my @bleeResults = $blee->(); ... }

What does your main program look like?


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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^8: Forking Clients
by gepapa (Acolyte) on Oct 16, 2008 at 13:11 UTC

    The main program is essentially a test script, which communicates via rpc with another server which will execute system commands. There are a bunch of intermediary modules between the main test script and the actual point where the rpc call is made. This is pretty much why I am trying to dumb it down so I understand the basics.

    Here is what I want to do in the main program

    my $remoteServer = new Host($ip); ... #I want the following to run concurrently my @networkinfo = $remoteServer->getNetworkInfo(); my @sysLog = $remoteServer->getSystemLog(); my @scsiInfo = $remoteServer->getScsiInfo(); #So I have kicked all these off, I need to get the #networkinfo and scsiInfo information back before #continuing. The sy +sLog I don't need, its going to be #grabbed way down the line, possibly at the end of the #program ... package Host; sub getNetworkInfo { ($self) = @_; my @results = $self->rpc('RPCService::system_call', 'ipconfig /all' +); return @results; } sub getScsiInfo { ($self) = @_; my @results = $self->rpc('RPCService::system_call', 'scsinit -a'); return @results; } sub getSystemLog { ($self) = @_; my @results = $self->rpc('RPCService::system_call', 'eventlog -a'); return @results; } sub rpc { ($self, $func, $command) = @_; my $ip = $self->getIP(); #start threaded/process code here ..??.. my $port = $self->getPort(); my $connection = ClarRPC->connect($ip, $port); my @resp = $connection->rpc($func, $command); $connection->disconnect(); ..??.. #end threaded/process code here }

    Let me know if I need to clear anything up. Thanks!

      You keep skipping over the important part--the bit above that is just comments--so I'll ask a very specific question.

      You've started all your remote commands--they're running asynchronously. You've done anything else you might want to do before you need the results of the first one--say the getNetworkInfo() in your example--and you are now ready for those results. When you started that command, you got back a handle as I suggested above, and you test the handle to see if the results are ready. What do you do if not?

      What are you going to do in the else clause below?

      my $networkinfo = $remoteServer->getNetworkInfo(); my $sysLog = $remoteServer->getSystemLog(); my $scsiInfo = $remoteServer->getScsiInfo(); ... anything else that needs doing ## Now you're ready for the network info my @networkinfo; if( $networkinfo ) { @networkinfo = $networkinfo->(); } else { ## What would you do here? }

      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.

        If I was at the point where I needed the information, I would wait for some specified amount of time. If it timesout I would kill the process and most likely die.

        Could you expand upon the use of the handles, I can't say I have ever used this way of doing things. Thanks.