how it handles that pool underneath a prefork mpm is a mystery to me.
The same way it handles pools under threaded mpm. Interpreter pools have nothing to do with threads. Under both mpm you create several interpreters under the same process and then you use them, regardless whether you are running in the process w/o threads or w/ threads.
but I bring it up here because it seems like checking for perl threads may provide all the data you need to make the decision on whether full/limited module loading makes sense - it really depends on how prefork + threaded perl ends up behaving, which we will probably only really know after some experimentation.
It's not the thing you want to do based on the above explanation. Regardless of having perl w/ ithreads, you want to preload things only for non-threaded mpm.
hmmm... I'm reading exactly the opposite from your explanation (which I'm sure is my fault :)
if threaded perls use interpreter pools regardless of whether the mpm is threaded or prefork, then I would think that perl would then be the deciding factor on whether or not you want to preload everything or not.
that is, a non-threaded perl can only run under prefork, so there you are forced into the old model. but a threaded perl automatically moves to interpreter pools, which have the "large parent means longer clone times and other memory hog issues" problem. so, threaded perls under prefork or worker makes no difference - you still don't want to create a large parent under prefork since it uses interpreter pools under threaded perls.
so, I gather that I'm missing a largish point, then :)
--Geoff
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
