However I think it is possible to make the architecture more flexible to allow pools sharing across specific vhosts, or even location containers (if the scope is set to be only for the handler). e.g. something like:
#base server
<TIPool A> # parameters </TIPool> <TIPool B> # parameters </TIPool>
<VirtualHost ...> PerlUseTiPool A </VirtualHost> <VirtualHost ...> PerlUseTiPool A </VirtualHost>
<VirtualHost ...> PerlUseTiPool B </VirtualHost> <VirtualHost ...> PerlUseTiPool B </VirtualHost>
Yeah, that would do it. I don't know how many people will need this, probably not so many. And there might be a sufficient work-around in those rare (?) cases involving multiple Apache instantiations and a proxy server to tie it all together. Something like the high-volume configurations I've seen documented, only with one mod_perl-enhanced server for each TIPool.
The code to implement blocks (e.g. <TIPool>...</TIPool>) in config files is pretty gnarly, too. I know it's already there for <Perl>, it's one of the places I looked when I was considering doing one of my own and wanted to see an example. The Apache framework is pretty strong for putting in new directives, but not so much for adding new blocks.
Actually you can't quite do that in a 3rd party module. Currently the pools are internal to mod_perl. Making this customizable will require adding hooks to the internal tipool mechanism. When I wrote the above pseudo-config I was suggesting an internal support for these.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
