perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Foertsch <torsten.foert...@gmx.net>
Subject Re: [PATCH] please review: interpreter allocation
Date Wed, 26 Sep 2007 17:44:30 GMT
Hi Gozer,

On Tuesday 25 September 2007 15:52, Torsten Foertsch wrote:
> I think pnotes need to be dropped whenever an interpreter is freed.

Currently $c->pnotes are dropped in a connection pool cleanup while $r->pnotes 
are dropped just after PerlCleanupHandler. A comment in 
modperl_util.c:modperl_pnotes says:

        /* XXX: It would be nice to be able to do this with r->pnotes, but
         * it's currently impossible, as modperl_config_request_cleanup()
         * is responsible for running the CleanupHandlers, and it's cleanup
         * callback is registered very early. If we register our cleanup here, 
         * we'll be running *before* the CleanupHandlers, and they might still
         * want to use pnotes...
         */

My idea to resolve this problem is why not create a subpool of $r->pool and 
register the PerlCleanupHandler with this pool?

Destruction of subpools is the first thing apr_pool_destroy does. That way a 
PerlCleanupHandler is run always before any $r->pool cleanups.


Another question, with the previous logic with scope==handler a 
PerlCleanupHandler was run each time the interpreter was put back to the 
interpreter pool. This was also the time when pnotes were dropped. Now the 
CleanupHandler is called at the end of the request even with scope==handler. 
So if for example a transhandler uses pnotes and the interpreter is put back 
after the translation phase these pnotes are not dropped.

What do you think would be better:

- if a populated pnotes hash locks the interpreter just like a new pool does

or

- if we add some logic to drop $r->pnotes and $c->pnotes if the interpreter is 
freed?

The question thus is does the InterpScope overrule allocated resources or do 
they overrule the scope?

Torsten

Mime
View raw message