This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: Mike McLagan <mmclagan@invlogic.com> From: Ged Haywood <ged@www2.jubileegroup.co.uk> Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) Date: Fri, 8 Feb 2002 02:42:31 +0000 (GMT) Hi again, On Thu, 7 Feb 2002, Mike McLagan wrote: > On Fri, 8 Feb 2002 01:18:19 +0000 (GMT), Ged Haywood wrote: > > >On Thu, 7 Feb 2002, Mike McLagan wrote: > > > >> >Isn't this mentioned in the mod_perl Guide? > >> > > >> >http://perl.apache.org/guide > >> > > >> > >> I dug thru the guide and I found no mention at all of anything > >> similar to this. > > > >http://perl.apache.org/guide/porting.html > > Could you give me the specific jump tag for the section you are refering to please? =head3 Reloading Configuration Files .... .... When the require(), use() and do() operators successfully return, the file that was passed as an argument is inserted into C<%INC> (the key is the name of the file and the value the path to it). Specifically, when Perl sees require() or use() in the code, it first tests C<%INC> to see whether the file is already there and thus loaded. If the test returns true, Perl saves the overhead of code re-reading and re-compiling; however calling do() will (re)load regardless. You generally don't notice with plain perl scripts, but in mod_perl it's used all the time; after the first request served by a process all the files loaded by require() stay in memory. If the file is preloaded at server startup, even the first request doesn't have the loading overhead. We use do() to reload the code in this file and not require() because while do() behaves almost identically to require(), it reloads the file unconditionally. If do() cannot read the file, it returns C<undef> and sets C<$!> to report the error. If do() can read the file but cannot compile it, it returns C<undef> and sets an error message in C<$@>. If the file is successfully compiled, do() returns the value of the last expression evaluated. ===