perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@covalent.net>
Subject Re: [Patch] stubs for cleaning up of r, scfg and dcfg
Date Thu, 01 Nov 2001 21:56:50 GMT
On Tue, 30 Oct 2001, Philippe M. Chiasson wrote:
 
> Actually, now that I look at it, I started to dislike this solution already, sorry.
> Whenever some module wants to associate something in a request/server/dir object,
> you'd have to add cleanup code to one of the cleanup_register functions.
> 
> Would it be okay for something like $r->pnotes to directly register it's own
> cleanup function when or if it has to create a new HV to free it later ?
> 
> Or if this is likely to happen a lot, would it make sense to abstract this
> a bit more and provide a more generic way to register the stuff you created
> with malloc and make sure it's automatically freed whenever it should be ?
> 
> Here is an example of a working, not leaking pnotes implementation that cleans
> up after itself.  If you ask me, it's a tiny bit more complicated then it should be,
> but here it is.

thanks, but don't forget the discussion below.  i haven't had a chance to
finish implementing the interpreter pool cleanup mechanism.  hopefully
will soon and it'll do the trick for properly cleaning up pnotes.

Date: Thu, 11 Oct 2001 08:50:58 -0700 (PDT)
From: Doug MacEachern <dougm@covalent.net>
To: "Philippe M. Chiasson" <gozer@cpan.org>
cc: dev@perl.apache.org
Subject: Re: Timing/location for proper rcfg cleanup ?
In-Reply-To: <20011011131840.A19360@eXtropia.com>
Message-ID: <Pine.LNX.4.21.0110110846260.28538-100000@mako.covalent.net>

On Thu, 11 Oct 2001, Philippe M. Chiasson wrote:
 
> Thanks, and might that be slightly more usefull in a macro like :

ok, i've added one for the moment.  but in the future, i hope nobody needs
it.  (see below)

> Good. But I discovered another slight annoyance I can't quite resolve.  ap_hook_create_request
> is used to create 'r' for every request, I guessed, but there doesn't seem to be a clean
way
> to handle destruction/cleaning of that request.  So now I am left wondering when/how
to step
> in just before a request obj is de-allocated, to free stuff that wasn't allocated with
apr_pools.

you can use a cleanup in r->pool.  however, i'm thinking in general there
should be a cleanup mechanism for the interpreter pool, so cleanups can 
happen when the interpreter is put back into the pool.  because at the
moment, pnotes will break if PerlInterpScope is configured to handler or
subrequest.  because the interpreter will have already been put back into
the pool by the time r->pool cleanups are run in these cases.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message