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

You need to wrap the while loop in a for loop that iterates once for each client you start: 

use strict;
use threads;
use threads::shared; ### I omitted this from my example above initiall
+y.
use Thread::Queue;
use ClarRPC;

my $queue = new Thread::Queue;

rpc('10.15.51.208', '1300', 'ping -n 50 10.15.51.208');
rpc('10.15.51.208', '1301', 'ping -n 10 10.15.51.208');
rpc('10.15.51.208', '1302', 'ping -n 50 10.15.51.208');

for( 1 .. 3 ) { ## Must iterate once for each thread started ###
    while (my $ref = $queue->dequeue) {
        my ($port, @results) = @$ref;
        print "$port : @results\n";
    }
}

sub rpc
{
    my ($ip, $port, $command) = @_;
    async{
        my $connection = ClarRPC->connect($ip, $port);
        my @resp :shared = $connection->rpc(
              'ClarRPCService::system_call', $command
        );
        $connection->disconnect();
        unshift(@resp, $port);
        $queue->enqueue(\@resp, undef);
    }->detach
}

[download]
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^4: Forking Clients
by gepapa (Acolyte) on Oct 15, 2008 at 17:55 UTC
    Yes, sorry for overlooking that. I have a few general questions more about understanding and extending this concept.

    This is a rather simple proof of concept, the final implementation would involve the rpc function being called from multiple different places, possibly simultaneously, in this case I want the caller to wait until its response is ready, when it is it should grab it and go on, while the other callers continue to wait.

    In Pseudo code it would be some thing like this:

    function rpc
    do thread and queueing stuff in here
end rpc


function blah
  rpc(IP, port2, command)
  look at queue see if your result is there
  if it is not
     wait
  else
     do other stuff with the info
end blah

function blee
  rpc(IP, port1, command)
  look at queue see if your result is there
  if it is not
     wait
  else
     do other stuff with the info
end blah

    [download]

    These function may very well call rpc at the same time, they will always use different port numbers. How would I go about using the queue to determine if my information is back, since in each instance of the call I won't know how many ports I have open, it only knows about the port it was told to use. Should I dequeue check the port/result and if it doesn't match enqueue it again?

    I really appreciate all your help.

[reply]
[d/l]
      it only knows about the port it was told to use. Should I dequeue check the port/result and if it doesn't match enqueue it again?

      No. What you are describing probably requires a completely different architecture to your OP code. But you first need to ask yourself a few questions.

      The first problem is how are you ever going to get to call blee() once you've called blah()?

      Ie. In the code that calls blah() and blee(), as you've described it in this post, once you call the first of these, it is going to block until it gets it's results, so you won't be able to call the second until the first has finished.

      So how can "These function may very well call rpc at the same time," be so?

      Once you decide how the top level of your code is going to operate, then you can decide how best to structure it?

      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.
[reply]
[d/l]
[select]

        Good point, and maybe I am approaching this the wrong way. But here is what I would like to do.

        I have a main program, which has a bunch of things it needs to do. From it I want to spawn off a function that will make a call, that function will wait for a response. The main program itself should not wait for it to come back, it should continue on spawning off other functions, or doing basic prints or function calls.

        When the spawned off function is done with its work,it would be great if there would be some interrupt which would let me know that it is, if needed I could periodically call a piece of code to check to see if its done.

        Does this explain it better?

        I really appreciate your help with this.

[reply]

In Section Seekers of Perl Wisdom