On Sunday 17 April 2011, Torsten Förtsch wrote: > On Tuesday, April 12, 2011 18:24:28 William A. Rowe Jr. wrote: > > Suggestion - an EXEC_ON_READ 'DynamicModulesMax' directive, which > > would let us conf_vector_length = total_modules + > > dyn_modules_max; after the read_config, and finally lock down > > conf_vector_length = total_modules; at the end of post_config. > > WDYT? > > The attached patch implements the DynamicModulesMax directive. It > can appear anywhere in the config file but is best placed *before* > any LoadModule directive. Up to post_config the number of > prelinked modules plus DynamicModulesMax is used as > conf_vector_length. In core_post_config the length is then settled > on total_modules.
I don't really like that. The admin should not have to count the LoadModule directives in order to tune DynamicModulesMax for minimum memory usage. Httpd should do the counting. Maybe something like this: - normally, conf_vector_length is adjusted after all EXEC_ON_READ directives have been processed - a module that wants to add modules later (like mod_perl) could call some function in its insert_hooks function, which would cause the adjustment of conf_vector_length to happen in post_config instead The function to be called could optionally take a number of module slots that should be kept in reserve. Then conf_vector_length would be adjusted to total_modules + reserve after all EXEC_ON_READ is done, and to total_modules in post_config. Or maybe the reserve should simply be set by some new directive like DynamicModulesMax? What do you think? BTW, I think there is something fishy with PerlLoadModule (or at least the documentation): The docs says that perl modules can use Apache2::Const::EXEC_ON_READ, but this cannot work because PerlLoadModule itself is executed too late. Cheers, Stefan
