Thread::Pool is a very, very complicated, over-engineered way of doing something very simple.
If you are having problems with threads, using Thread::Pool won't make those problems go away.
What it will do is exacerbate any and every small problem you encounter, and turn it into a complete nightmare to try and track down and debug.
This is a complete working example of a thread pool:
#! perl -slw
use strict;
use threads;
use Thread::Queue;
## The worker sub
sub worker {
my $tid = threads->tid;
my $Q = shift;
while( my $workitem = $Q->dequeue ) {
print "$tid: processing $workitem";
sleep $workitem;
}
}
### How many in the pool
our $T //= 4;
### The queue
my $Q = new Thread::Queue;
### Start the pool
my @workers = map threads->create( \&worker, $Q ), 1 .. $T;
### Give'm some stuff to do
$Q->enqueue( map int( rand 10 ), 1 .. 100 );
### Do some other stuff here while they do their thing.
### Tell'm they're done
$Q->enqueue( (undef) x $T );
### Wait for'm to finish up
$_->join for @workers;
### finished.
Now, go look inside Thread::Pool. Then Thread::Conveyor; Then Thread::Conveyor::Monitored. Then Thread::Tie. The Thread::Tie::Thread....I got bored looking at this point. Now imagine what happens when something goes wrong?
Using that lot is an absurd response to a problem with leakage. It won't fix the leaks. It will exacerbate them and make them much, much harder to track and deal with.
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.
|