Torsten Foertsch wrote:
> Hi,
>
> is it valid to say that modperl_interp_pool_select is
called only at request
> time and hence the passed pool is allways the request
pool?
In the general case, yes. There is however one instance
where it is also called
to acquire an interpreter at config merging time.
> I have run the test suite and in the few occasions this
function is called it
> is the request pool. But that does not mean that it
allways is.
A quick look at src/modules/perl/modperl_module.c:
152 /*
153 * XXX: vhosts may have different parent
interpreters.
154 */
155 static void *modperl_module_config_merge(apr_pool_t
*p,
156 void
*basev, void *addv,
157 int type)
[...]
185 #ifdef USE_ITHREADS
186 interp = modperl_interp_pool_select(p, s);
187
MP_PERL_CONTEXT_STORE_OVERRIDE(interp->perl);
188 #endif
And in the case of server configuration merging (happens at
startup),
there would be no request, and no request pool.
It goes something like this:
790 const char *modperl_module_add(apr_pool_t *p,
server_rec *s,
791 const char *name, SV
*mod_cmds)
792 {
[...]
816 modp->create_dir_config =
modperl_module_config_dir_create;
817 modp->merge_dir_config =
modperl_module_config_dir_merge;
818 modp->create_server_config =
modperl_module_config_srv_create;
819 modp->merge_server_config =
modperl_module_config_srv_merge;
Which is how we get our configuration merging callbacks
registered
with httpd.
Also, Perl modules can register their own configuration
merging:
xs/Apache2/Module/Apache2__Module.h:
78 static MP_INLINE void
mpxs_Apache2__Module_add(pTHX_
79 char
*package,
80 SV
*cmds)
81 {
[...]
89 s = modperl_global_get_server_rec();
90 error =
modperl_module_add(s->process->pconf, s, package,
cmds);
In any case, I am not sure what pool that ends up being, but
it's probably
pconf.
------------------------------------------------------------
------------
Philippe M. Chiasson GPG: F9BFE0C2480E7680
1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.or
g/ m/gozer (apache|cpan|ectoplasm).org/
|
