mark at geekhive
May 2, 2011, 11:25 AM
Post #9 of 16
oops... Anyhow, to continue:
If I had to guess I'd say bric_queued would be an easier debugging
environment than mod_perl, and there's a pretty good chance that if we can
fix the leak under the one it will cover the other as well, since all
bric_queued does is call a burner.
I wonder if it's worth giving up a few nights or a weekend for this.
On Mon, May 2, 2011 at 20:23, Mark Jaroski <mark [at] geekhive> wrote:
> Hi Alex,
> That's a very good point. Maybe we should consider hunting the leak down
> On Mon, May 2, 2011 at 17:47, Alex Krohn <alex [at] gt> wrote:
>> Hi Mark,
>> > A memory leak is when a program requests memory from the system, and
>> > fails to give it back when it's done. As I understand there is some
>> > controversy over whether the behaviour of Perl is considered a memory
>> > or not, since apparently it fails to give the memory back by design.
>> > At least that's my recollection.
>> > In practice what it means is that you can't have a long-running perl
>> > daemon that does anything very interesting. You have to kill it off from
>> > time to time and restart it.
>> Perl doesn't release the memory allocated, but does reuse it. So you can
>> have Perl daemon's running for a long period of time and doing
>> interesting things, just can't have them keep growing in memory (much
>> like any language). =)
>> Alex Krohn <alex [at] gt>