Well, the following does the equivalent (of the bit you have shown) without using Thread::Pool.

my $Qin = new Thread::Queue;
my $Qout = new Thread::Queue;

my @pool = map{ 
    threads->new( \&telnet2Cli, 'show version' )->detach 
} 1 .. 5;

my $running : shared = @pool;
$Qin->enqueue( @values );

sleep 1 while $running;

my @versionOuput = $Qout->dequeue;
[download]

Of course, that requires that the telnet2Cli sub be written to use the $Qs, but that highlights a problem with Thread::Pool. It isn't a Pool!

With a pool, the members of the pool loop over the worklist processing items until there are no more and then die. That is to say, only 5 (in this case) threads are ever created. These are re-used until the work is finished.

From your snippet (though not confirmed by from the module source, as it is so complex it is hard to follow), I conclude that Thread::Pool, creates a new thread for each work item. The workers => 5 parameter simply restricts the number of concurrent threads to 5 at any given time, but ultimately, one thread will have been created for every value in @values.

Starting ithreads is not cheap, and starting a new thread for every item throws away most of the benefits of using threads.