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.

BrowserUK,

Thanks you for your reply. The fact that I am using a single double Xeon machine was just to specfify the architeture on which I am trying to test a threading program.
Where I am, I'll have to do very repetitive tasks over different chunks of data, and we have plenty of four processors opterons, where threading could lead to a considerable gain of speed.

Now, I agree with all your points. Thread::Pool is over complex and does not install without trouble (with all respect due to the author). Developing any module for general use is going to be hard in an effective manner.
I will probably end up coding my own little version based on the code you have submitted in Building a thread pool.

Thanks,

I'd love to help if I can. If the application is proprietory, perhaps there's a generalised and sanitised description that would suffice as a substitute?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.