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.

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->();
    ...
}
[download]

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."

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
}
[download]

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

What does the function you spawn off do with the response? Must the main program know what that spawned process has done or that it was successful?

If you only need to know that the spawned process is complete, then that's pretty easy. A non-blocking wait could help with that if you plan on rolling your own.

If, however, the main program needs to know what's going on in the spawned processes then you have a more complicated issue.

I recommend you get and read a book by Stevens. Perhaps UNIX Network Programming, Volume 2, Second Edition: Interprocess Communications, Prentice Hall, 1999 (ISBN 0130810819) or maybe Advanced Programming in the UNIX Environment, Addison-Wesley, 1992 (ISBN 0201563177).

Before you protest that you're not programming in C or that you're not using Unix, let me point out that the concepts are the same. The Unix family of OSes is the home of sockets, C, Perl, several forms of IPC, regular expressions as a computational tool, and more. Perl borrows heavily from C, Unix, and Unix-borne tools in its concepts. If you know Perl and how IPC works on Unix, then save for a few caveats about other OSes you're mostly set to do IPC in Perl.

The main program doesn't need to know what the thread is doing in "real-time", just that its done, and when it is, the main program needs to get the results of whatever the thread did. The caveat here is that the main program just needs to be able to do other stuff while the thread is doing its thing.

I understand how I can spawn the thread/process have it do its thing if there is no need for the main program to get the resultant information back from the thread, but the issue I seem to be having is that I can't get the information back from the thread/process without blocking. I guess I am just not understanding how to implement the non-blocking properly

Btw, I thank you for the suggestions, I will look at both, the more I know the better.