in reply to Re^8: perl 5.12.3 + threads + memory leak
in thread perl 5.12.3 + threads + memory leak

Why ? :)
  • Comment on Re^9: perl 5.12.3 + threads + memory leak

Replies are listed 'Best First'.
Re^10: perl 5.12.3 + threads + memory leak
by BrowserUk (Patriarch) on Feb 18, 2011 at 13:48 UTC

    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.