Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: domain of gcaa-apreq-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Mail-Followup-To: apreq-dev@httpd.apache.org
To: apreq-dev@httpd.apache.org
From: Joe Schaefer <joe+gmane@sunstarsys.com>
Subject: Re: Parsing error when parsing the second time
Date: Sat, 31 Mar 2007 00:02:47 -0400
Lines: 25
Message-ID: <87648i5ac8.fsf@gemini.sunstarsys.com>
References: <DE87FDD4-7912-49A9-9234-F3F8B6662A47@hybridized.org>
	<87abxu5bfe.fsf@gemini.sunstarsys.com>
	<A413A622-6ADD-4397-B6FF-822ADDB28D33@hybridized.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Mail-Copies-To: never
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Cancel-Lock: sha1:ZeQi2Lqe72GuJQ5YvpeanoPfFOM=
Sender: news <news@sea.gmane.org>

Andy Grundman <andy@hybridized.org> writes:

> The APR::Pool docs warn about memory leakage if using a global pool,
> do you think I should be calling $pool->clear after every time I use
> it?

No.  I don't know how you're planning to make use of
APR::Request in a standalone application, but I would
recommend creating a global pool and letting perl
clean it up at program exit.  If you run short of
memory, calling $pool->clear somewhere in the middle
of your program will hose all your APR::Request structs,
so try to avoid that.

You're wandering into largely unchartered territory
by using APR:: outside of mod-perl, so  I would try
to be conservative if possible, and follow the examples 
in the test code. APR::Pool has a good set of tests,
so I'm really not sure the problem is there or somewhere
in apreq's xs.  It just stood out that you were using
a new pool for each subroutine call, which probably
isn't the best way to do things.

-- 
Joe Schaefer