[31874] in Perl-Users-Digest
Perl-Users Digest, Issue: 3137 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 20 06:09:23 2010
Date: Mon, 20 Sep 2010 03:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 20 Sep 2010 Volume: 11 Number: 3137
Today's topics:
Re: Confused about closures <xhoster@gmail.com>
Re: Memory leak with threads <nospam-abuse@ilyaz.org>
Re: Memory leak with threads <xhoster@gmail.com>
Re: Memory leak with threads <nospam-abuse@ilyaz.org>
Re: Memory leak with threads <jcombe@gmail.com>
Re: Memory leak with threads <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 17 Sep 2010 19:45:18 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Confused about closures
Message-Id: <4c951a10$0$18801$ed362ca5@nr5-q3a.newsreader.com>
Krishna Chaitanya wrote:
> Hi,
>
> Following's an extract from Perl FAQ 7.13 (closures):
>
> ****************
> Closures are often used for less esoteric purposes. For example,
> when
> you want to pass in a bit of code into a function:
> my $line;
> timeout( 30, sub { $line = <STDIN> } );
> If the code to execute had been passed in as a string, '$line =
> <STDIN>', there would have been no way for the hypothetical
> timeout()
> function to access the lexical variable $line back in its
> caller's
> scope.
> ****************
>
> I'm not clear about what's being said here...why would timeout need to
> access $line here at all? What would be wrong with:
>
> timeout(30,scalar(<STDIN>));
Two things. First of all, that would wait (potentially forever) for a
line to be read from STDIN, *before* timeout got executed. This would
presumably defeat the purpose of having a subroutine named timeout. But
this has nothing to do with closures.
Second, if you want the next line in STDIN to be thrown away, that would
be fine. But presumably you want it to be assigned to $line, otherwise
you wouldn't be assigning it to $line.
Xho
------------------------------
Date: Sat, 18 Sep 2010 16:52:24 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Memory leak with threads
Message-Id: <slrni99ri8.sb6.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-09-17, Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
> You need to measure the process space from the OS, not from Perl,
Measuring from Perl is OK if Perl was build using "my" malloc().
> which after all likely cannot be trusted if it is leaking memory.
With "my" malloc(), trust and leaks become orthogonal issues.
Yours,
Ilya
------------------------------
Date: Sat, 18 Sep 2010 16:38:43 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Memory leak with threads
Message-Id: <4c954d4a$0$21665$ed362ca5@nr5-q3a.newsreader.com>
Ilya Zakharevich wrote:
> On 2010-09-17, Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
>> You need to measure the process space from the OS, not from Perl,
>
> Measuring from Perl is OK if Perl was build using "my" malloc().
Well, OK. But how do you do it? Devel::Size certainly isn't the way.
Xho
------------------------------
Date: Sun, 19 Sep 2010 04:19:23 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Memory leak with threads
Message-Id: <slrni9b3qb.tq2.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-09-18, Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
>> Measuring from Perl is OK if Perl was build using "my" malloc().
> Well, OK. But how do you do it? Devel::Size certainly isn't the way.
Sure. For one-off, use PERL_DEBUG_MSTATS=1 (or 2); for continuous
loop, one should use the interface (IIRC) in Devel::Peek. This should
be in one of perldebug*.pod (do not know where it is split to
nowadays; when I documented it, there was exactly one perldebug...).
Ilya
------------------------------
Date: Mon, 20 Sep 2010 01:07:40 -0700 (PDT)
From: Jon Combe <jcombe@gmail.com>
Subject: Re: Memory leak with threads
Message-Id: <bcc3df4f-1e43-4ce6-867b-be2f2762f017@z25g2000vbn.googlegroups.com>
> I put a test together. See what you get with this.
Oddly, I get this on 5.8.8.
Can't locate auto/threads/is_running.al in @INC (@INC contains: /usr/
lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/
site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/
5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/
lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /
usr/lib/perl5/5.8.8 .) at thread_test.pl line 24
However it does work on 5.12.2 and I get the same output you get
(other than the memory addresses being different of course). With the
sleep in place I get this output which all looks OK.
thread 1 start
thread 2 start
thread 3 start
thread 4 start
thread 5 start
thread 6 start
thread 7 start
thread 8 start
thread 9 start
thread 10 start
ALL:- :
threads=SCALAR(0x8c7c500)
threads=SCALAR(0x8c7c520)
threads=SCALAR(0x8c7c540)
threads=SCALAR(0x8c7c560)
threads=SCALAR(0x8c7c580)
threads=SCALAR(0x8c7c5a0)
threads=SCALAR(0x8c7c5c0)
threads=SCALAR(0x8c7c5e0)
threads=SCALAR(0x8c7c600)
threads=SCALAR(0x8c7c620)
RUNNING:- :
threads=SCALAR(0x8c7c500)
threads=SCALAR(0x8c7c520)
threads=SCALAR(0x8c7c540)
threads=SCALAR(0x8c7c560)
threads=SCALAR(0x8c7c580)
threads=SCALAR(0x8c7c5a0)
threads=SCALAR(0x8c7c5c0)
threads=SCALAR(0x8c7c5e0)
threads=SCALAR(0x8c7c600)
threads=SCALAR(0x8c7c620)
JOINABLE:- :
DETACHED:- :
thread 1 done
thread 2 done
thread 3 done
thread 4 done
thread 5 done
thread 6 done
thread 7 done
thread 8 done
thread 9 done
thread 10 done
RUNNING:- :
JOINABLE:- :
DETACHED:- :
If I put an exit right under the initial for loop as you said I get
some thread messages:-
Perl exited with active threads:
1 running and unjoined
9 finished and unjoined
0 running and detached
Jon
------------------------------
Date: Mon, 20 Sep 2010 10:27:42 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Memory leak with threads
Message-Id: <e1mjm7-8ui2.ln1@osiris.mauzo.dyndns.org>
Quoth Jon Combe <jcombe@gmail.com>:
> > I put a test together. See what you get with this.
>
> Oddly, I get this on 5.8.8.
>
> Can't locate auto/threads/is_running.al in @INC (@INC contains: /usr/
That'll be because threads uses AutoLoader, and you're using an old
version of threads.pm which doesn't support ->is_running.
You can upgrade threads from CPAN on older perls.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3137
***************************************
