Re^3: 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."

Comment on Re^3: Forking Clients Download Code

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]
Re^5: Forking Clients by BrowserUk (Patriarch) on Oct 15, 2008 at 18:31 UTC
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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l] [select]
Re^6: Forking Clients by gepapa (Acolyte) on Oct 15, 2008 at 19:05 UTC
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]
Re^7: Forking Clients by BrowserUk (Patriarch) on Oct 15, 2008 at 23:04 UTC
Re^8: Forking Clients by gepapa (Acolyte) on Oct 16, 2008 at 13:11 UTC
Some notes below your chosen depth have not been shown here
Re^7: Forking Clients by mr_mischief (Monsignor) on Oct 15, 2008 at 21:05 UTC
Re^8: Forking Clients by gepapa (Acolyte) on Oct 16, 2008 at 12:31 UTC
Some notes below your chosen depth have not been shown here


go ahead... be a heretic
	PerlMonks