Torsten Foertsch wrote: > 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?
That would work. > Destruction of subpools is the first thing apr_pool_destroy does. That way a > PerlCleanupHandler is run always before any $r->pool cleanups. I like it, that's very simple and could move the cleanup logic out of there, as well as that long, annoying comment ;-) > Another question, with the previous logic with scope==handler a > PerlCleanupHandler was run each time the interpreter was put back to the > interpreter pool. And I am not sure this was a planed feature. > This was also the time when pnotes were dropped. Definitely not a feature then, IMO. > 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 +1 > or > > - if we add some logic to drop $r->pnotes and $c->pnotes if the interpreter > is > freed? Nah, that's not what would be expected of pnotes. You expect pnotes to be a safe place to stash stuff for the duration of $r/$c > The question thus is does the InterpScope overrule allocated resources or do > they overrule the scope? I would see InterpScope as advisory, really. When I say InterpScope handler, I am asking for as much concurrency as possible, important word: possible. So if you stick stuff in pnotes, all bets are off. We try our best, but it might mean that particular interpreter is tied up for the request. Sounds to me like that's the only way to keep doing the right thing with the overall behaviour of things (like pnotes). ------------------------------------------------------------------------ Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5 http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
signature.asc
Description: OpenPGP digital signature
