In addition to the good advice already posted, you may like to consider a serious remodel of your process. Rather than joining your threads to retrieve their result, you could setup a 'return queue'. Thus you start each worker thread - passing it $somedata and a reference to your return queue such as made by threads::shared::queue. Detach the thread, and forget you ever started it. In your worker sub, ->enqueue your processed return data , and exit the thread.
I have a snippet that demonstrates simple use of queues. The networking stuff is pretty poor and not related to your problem so best to ignore that.
This way you have a simple accessor to finished data in your main thread, by ->dequeue 'ing from your queue object. Once the detached worker threads enqueue their result , they can die a natural death (exit). Which should be reflected in the number that threads->list returns. As @threads_running falls below your 'apparent' optimal thread count - top up the pool by starting another thread
Of course I'm going to run off and try this now, but methinks the theory is ok
In reply to Re: Fun with threads
by submersible_toaster
in thread Fun with threads
by znu
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |