Skip Menu |
 

This queue is for tickets about the threads CPAN distribution.

Report information
The Basics
Id: 44493
Status: resolved
Priority: 0/
Queue: threads

People
Owner: Nobody in particular
Requestors: christian [...] hbr1.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.77



Subject: memory eating 1.72
Date: Mon, 23 Mar 2009 06:26:18 +0100 (CET)
To: bug-threads [...] rt.cpan.org
From: "Christian Mueller" <christian [...] hbr1.com>
Download (untitled) / with headers
text/plain 314b
when i tested a new module for threadsafety i found a bug in the perl threading model. the following test doesn't stop eating memory. i tested it with perl/5.10.0 and perl/5.8.8 and threads 1.72 on linux x64 use threads; retry: $t = threads->create( \&thread_sub ); $t->join; goto retry; sub thread_sub { }
Download (untitled) / with headers
text/plain 483b
ps. it does not happen on windows (active perl/5.10.0, threads/1.7.1). On Mo. 23. Mär. 2009, 17:47:55, christian@hbr1.com wrote: Show quoted text
> when i tested a new module for threadsafety i found a bug in the perl > threading model. the following test doesn't stop eating memory. i
tested Show quoted text
> it with perl/5.10.0 and perl/5.8.8 and threads 1.72 on linux x64 > > use threads; > > retry: > > $t = threads->create( \&thread_sub ); > $t->join; > > goto retry; > > sub thread_sub { > } > >
CC: christian [...] hbr1.com
Subject: Re: [rt.cpan.org #44493] memory eating 1.72
Date: Wed, 25 Mar 2009 09:41:17 -0400
To: pp <perl5-porters [...] perl.org>, David Mitchell <davem [...] iabyn.com>, bug-threads [...] rt.cpan.org
From: "Jerry D. Hedden" <jdhedden [...] cpan.org>
Download (untitled) / with headers
text/plain 655b
Christian Mueller wrote: Show quoted text
>  Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=44493 > > > when i tested a new module for threadsafety i found a bug in the perl > threading model. the following test doesn't stop eating memory. i tested > it with perl/5.10.0 and perl/5.8.8 and threads 1.72 on linux x64 > > use threads; > > retry: > > $t = threads->create( \&thread_sub ); > $t->join; > > goto retry; > > sub thread_sub { > }
He also wrote: Show quoted text
> it does not happen on windows (active perl/5.10.0, threads/1.7.1).
Hi, Dave, et al, Is this really a bug or is it a matter of lagging to clean up memory from a fast loop that creates and destroys threads?
CC: pp <perl5-porters [...] perl.org>, bug-threads [...] rt.cpan.org, christian [...] hbr1.com
Subject: Re: [rt.cpan.org #44493] memory eating 1.72
Date: Wed, 25 Mar 2009 14:55:51 +0000
To: "Jerry D. Hedden" <jdhedden [...] cpan.org>
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 1.3k
On Wed, Mar 25, 2009 at 09:41:17AM -0400, Jerry D. Hedden wrote: Show quoted text
> Christian Mueller wrote:
> >  Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=44493 > > > > > when i tested a new module for threadsafety i found a bug in the perl > > threading model. the following test doesn't stop eating memory. i tested > > it with perl/5.10.0 and perl/5.8.8 and threads 1.72 on linux x64 > > > > use threads; > > > > retry: > > > > $t = threads->create( \&thread_sub ); > > $t->join; > > > > goto retry; > > > > sub thread_sub { > > }
> > He also wrote:
> > it does not happen on windows (active perl/5.10.0, threads/1.7.1).
> > Hi, Dave, et al, > Is this really a bug or is it a matter of lagging to clean up > memory from a fast loop that creates and destroys threads?
On the second and subsequent thread creations, $t holds a pointer to the remains of the previous thread; this gets cloned into the new thread, and so the previous thread never gets freed. Rinse and repeat. So its not a bug, just a non-obvious consequence of the fact that a new thread inherits a copy of everything in the old thread. If you undef $t before each new thread creation, the problem goes away: ... undef $t; $t = threads->create( \&thread_sub ); -- The Enterprise successfully ferries an alien VIP from one place to another without serious incident. -- Things That Never Happen in "Star Trek" #7
Download (untitled) / with headers
text/plain 705b
Show quoted text
> On the second and subsequent thread creations, $t holds a pointer to > the remains of the previous thread; this gets cloned into the new
thread, Show quoted text
> and so the previous thread never gets freed. Rinse and repeat. > > So its not a bug, just a non-obvious consequence of the fact that a
new Show quoted text
> thread inherits a copy of everything in the old thread. If you undef
$t Show quoted text
> before each new thread creation, the problem goes away: > > ... > undef $t; > $t = threads->create( \&thread_sub ); > > >
use threads; retry: undef $t; $t = threads->create( \&thread_sub ); $t->join; undef $t; goto retry; sub thread_sub { undef $t; } sorry, but it makes no different. it still eats up the memory.
Download (untitled) / with headers
text/plain 251b
without any global variable, and still eating memory... use threads; use Time::HiRes; retry: threads->create( \&thread_sub ); Time::HiRes::usleep( 10_000 ); goto retry; sub thread_sub { #print threads->self->tid, "\n"; threads->self->detach; }
Download (untitled) / with headers
text/plain 587b
I have updated the threads POD to note that this situation exists, and added the advice to reuse threads in long-lived apps. I've also created an example script that illustrates this concept. These will go out with the next release (whenever that occurs). On Wed Mar 25 13:17:02 2009, CHRMUE wrote: Show quoted text
> without any global variable, and still eating memory... > > use threads; > use Time::HiRes; > > retry: > > threads->create( \&thread_sub ); > > Time::HiRes::usleep( 10_000 ); > goto retry; > > sub thread_sub { > #print threads->self->tid, "\n"; > threads->self->detach; > }


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.