The point I've being trying to arrive at is that if, once you get to the point of needing the information, you have nothing else to do but wait for it to be available, then you do not need to do anything special.

The handles in this case are simply the thread handles:

my( $networkinfo ) = threads->create( 
    sub{ $remoteServer->getNetworkInfo() } 
);
my( $sysLog ) = threads->create( 
    sub{ $remoteServer->getSystemLog() }
);
my( $scsiInfo ) = threads->create( 
    sub{ $remoteServer->getScsiInfo() }
);

... anything else that needs doing

## Now you're ready for the network info
my @networkinfo = $networkinfo->join;

...

## Now you're ready for the scsi info
my @scsiinfo = $scsiInfo->join;

...

## Now you're ready for the syslog
my @syslog = $sysLog->join;
[download]

There are 3 things to note here:

1. Wrapping the method calls in subs on the thread create.

   As you cannot take a reference to a method, you have to wrap the method call in a sub to create a closure.

   In every other way, that method call should be exactly as it would be if no threading was involved.

2. The scalars used to hold the thread handles returned by the threads->create() must be placed in parens if the method is to return a list.

   This is to ensure that the method is called in a list context. Whatever context threads->create() is called in when the thread is started, is the context that will be transferred to thread when it starts.

3. The join will return the results of the method called.

   If the thread has completed when you call join, it will return teh results straight away. If it hasn't, it will block until it does.

   If you want the commands to time out after some period of time, that should be done internally to the method itself. It can then choose to either log and die, or return undef or an exception object to indicate that the command failed to complete, just as it would have to do if called synchronously.

The trick with threading, is that your code, at each level, should operate synchronously first. Then asynchronously.

Depending upon the design of your library, you might also use a thread internally to achieve the timeout, but that is a separate issue from the main code. You should not conflate that timeout mechanism, however it is achieved, with the mechanism for running the methods asynchronously.