Well. I've never managed to get Threads::Pool to work on my system. I just tried to reinstall the whole dependency chain from scratch and got test failures all the way up the chain from load module onward ending with this at the top of the chain:

t\Pool06....dubious
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED tests 1-21
        Failed 21/21 tests, 0.00% okay
Failed Test Stat Wstat Total Fail  Failed  List of Failed
----------------------------------------------------------------------
+---------
t\Pool01.t     1   256    42   83 197.62%  1-42
t\Pool02.t     1   256   337  673 199.70%  1-337
t\Pool03.t     1   256   403  803 199.26%  1 3-403
t\Pool04.t     1   256   202  403 199.50%  1-202
t\Pool05.t     1   256    37   73 197.30%  1-37
t\Pool06.t     1   256    21   41 195.24%  1-21
Failed 6/6 test scripts, 0.00% okay. 1041/1042 subtests failed, 0.10% 
+okay.
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2'
Stop.
[download]

With the greatest of respect to the author of these modules, I find them over-complex for what they attempt to do.

The code I posted in that thread has never been developed further because I found it impossible to write a single, simple & consistent interface that would cater for the many possible scenarios in which a "pool of threads" might be used. I'm also of the opinion that the more general that you make the interface to a library, the less usable it becomes, and the less effective it is for any given application. To that end, I prefer to use the basic threads/threads::shared (and often Thread::Queue) directly to construct the infrastructure I need for each particular application. I have yet to see sufficient pattern across a range of applications for thread pools to warrant the abstraction of a common part of it out into a separate library.

I don't really care about locking, ...

You'll have to explain wht you mean by that.

Why do you not care about locking? Are you saying that each of your threads will only use independent data and so there is no need for locking?

... and could just submit all my jobs and wait for all of them to be finished..

That statement suggests that you should not be considering threads at all.

On a dual processor machine, the probability is that if you ran all your code serially, it would finish more quickly than if you started a 100 threads simultaneously. Although the serial code would only utilise one cpu (at a given time), the OS would not be having to task swap each cpu between 50 threads.

The code you posted was obviously only an example, as it does nothing that requires or benefits from threads. If you were to post a synopsis of the actual application, then it would be possible to advise on strategies you might consider.