At 18.32 -0500 11/20/2001, Robert Landrum wrote: >> >If that is the case, My::Special::Module won't be loaded and compiled until the >very first time that someone hits /whatever. >> >>Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing >blocks. Although I do have 'PerlHandler' directives in <Location> and <Files> >blocks, the modules they use are preloaded prior to the enclosing block. We're hip >to shared memory :-) > >It just hit me.... That is why Apache::StatINC isn't working. > >We use Apache::StatINC on our development server, but we never preload any modules... > We just use > ><Location /whatever> >SetHandler perl-script >PerlHandler My::Special::Module ></Location> > >and Apache::StatINC works. > >If you preload, It's not going to put the module into %INC. Otherwise Apache::StatINC >would intentionally overwrite that shared memory and destroy the purpose for using >PerlModule in the first place.
If this is true, it is a change from prior behavior. (And a bit distressing.) I for one would not complain of Apache::StatINC dirtying memory pages -- I'm really only concerned with shared memory on a production server, and I wouldn't run StatINC outside of the development environment. Besides, I'm assuming that if I do my trick of calling 'use' in a <Perl> block (which DOES update %INC) that the module code pages are still shared. What is more distressing though is that StatINC may not be the only consumer of %INC. (e.g., Apache::Status does not report these modules in "Loaded Modules") The real trouble is that it is deviating from Doing the Right Thing by perl. >I could be wrong... but I think that the answer is that "It's not a bug, it's a >feature", and that the behavior is actually correct. > For the above reasons, I hope you are wrong. :-) But you may be right! David
