Re: does threads (still) memleak?

[BrowserUk]

This is either platform specific, or a bug introduced since 5.8.6 because your code above (with the addition of a counter to display how many threads have been created and joined), doesn't leak on my system using 5.8.6 and threads 1.71:

use threads;
use strict;
use warnings;

print $], ' ', $threads::VERSION, "\n";

my $sub1 = sub { my $a=[ 1 .. 10000] };

my $m = 0;

for (;;) {
    printf "\r%d\t", $m++;
    my $thr = threads->new( $sub1 )->join;
    undef $thr;
}



__END__
c:\test>junk
5.008006 1.71
3077    Terminating on signal SIGINT(2)

For proof, see this image. It shows the cpu, memory usage and IO activity for the process while the code above created and destroyed those 3000+ threads. The memory usage wobbles up and down a bit, but basically stays level at around 2.7 MB.

I note also that in the same thread that you cited, that dave_the_m says that "the bug is fixed in bleed perl"?. (Unfortunately he didn't see fit to inform us of the cause, or the affected platforms:()

So, you could try either reverting to 5.8.6 or possibly upgrading to recently announced the 5.8.9 release candidate.

I tried using 'forks' instead, which seems to solve the problem.

That's a pretty meaningless statement. It's like saying that taking the train cured your car's fuel consumption problem :)

[weismat]

I tried BrowserUk code on my Linux machine and 5.10 and saw no leak as well.
I am using ActiveState build 1001 and CentOS release 4.5.

[Anonymous Monk]

I see the same as you with v5.8.7, ActivePerl Build 813, WinXP.

[BrowserUk]

Thanks. It's looking more and more like the suspicions I've had and voiced about 5.8.8 and threads are right. Something pretty fundemental broke in that build and has only recently been corrected.

That why I stayed back at 5.8.6. (I forgot why I rejected 5.8.7--I seem to recall having some problem with it when it was first released--the installer or maybe PPM didn't work right).