apache2::reload.3

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

.PP
.Vb 3
\&  PerlModule Apache2::Reload
\&  PerlInitHandler Apache2::Reload
\&  PerlSetVar ReloadDirectories "/tmp/project1 /tmp/project2"
.Ve
.PP
You can further narrow the list of modules to be reloaded from the
chosen directories with \f(CW\*(C`ReloadModules\*(C'\fR as in:
.PP
.Vb 5
\&  PerlModule Apache2::Reload
\&  PerlInitHandler Apache2::Reload
\&  PerlSetVar ReloadDirectories "/tmp/project1 /tmp/project2"
\&  PerlSetVar ReloadAll Off
\&  PerlSetVar ReloadModules "MyApache2::*"
.Ve
.PP
In this configuration example only modules from the namespace
\&\f(CW\*(C`MyApache2::\*(C'\fR found in the directories \fI/tmp/project1/\fR and
\&\fI/tmp/project2/\fR (and their subdirectories) will be reloaded.
.ie n .Sh "Special ""Touch"" File"
.el .Sh "Special ``Touch'' File"
.IX Subsection "Special Touch File"
You can also declare a file, which when gets \f(CWtouch(1)\fRed, causes the
reloads to be performed. For example if you set:
.PP
.Vb 1
\&  PerlSetVar ReloadTouchFile /tmp/reload_modules
.Ve
.PP
and don't \f(CWtouch(1)\fR the file \fI/tmp/reload_modules\fR, the reloads
won't happen until you go to the command line and type:
.PP
.Vb 1
\&  % touch /tmp/reload_modules
.Ve
.PP
When you do that, the modules that have been changed, will be
magically reloaded on the next request. This option works with any
mode described before.
.Sh "Unregistering a module"
.IX Subsection "Unregistering a module"
In some cases, it might be necessary to explicitely stop reloading
a module.
.PP
.Vb 1
\&  Apache2::Reload\->unregister_module(\*(AqSome::Module\*(Aq);
.Ve
.PP
But be carefull, since unregistering a module in this way will only
do so for the current interpreter. This feature should be used with
care.
.SH "Performance Issues"
.IX Header "Performance Issues"
This modules is perfectly suited for a development environment. Though
it's possible that you would like to use it in a production
environment, since with \f(CW\*(C`Apache2::Reload\*(C'\fR you don't have to restart
the server in order to reload changed modules during software
updates. Though this convenience comes at a price:
.IP "\(bu" 4
If the \*(L"touch\*(R" file feature is used, \f(CW\*(C`Apache2::Reload\*(C'\fR has to \fIstat\fR\|(2)
the touch file on each request, which adds a slight but most likely
insignificant overhead to response times. Otherwise \f(CW\*(C`Apache2::Reload\*(C'\fR
will \fIstat\fR\|(2) each registered module or even worse\*(--all modules in
\&\f(CW%INC\fR, which will significantly slow everything down.
.IP "\(bu" 4
Once the child process reloads the modules, the memory used by these
modules is not shared with the parent process anymore. Therefore the
memory consumption may grow significantly.
.PP
Therefore doing a full server stop and restart is probably a better
solution.
.SH "Debug"
.IX Header "Debug"
If you aren't sure whether the modules that are supposed to be
reloaded, are actually getting reloaded, turn the debug mode on:
.PP
.Vb 1
\&  PerlSetVar ReloadDebug On
.Ve
.SH "Caveats"
.IX Header "Caveats"
.Sh "Problems With Reloading Modules Which Do Not Declare Their Package Name"
.IX Subsection "Problems With Reloading Modules Which Do Not Declare Their Package Name"
If you modify modules, which don't declare their \f(CW\*(C`package\*(C'\fR, and rely on
\&\f(CW\*(C`Apache2::Reload\*(C'\fR to reload them, you may encounter problems: i.e.,
it'll appear as if the module wasn't reloaded when in fact it
was. This happens because when \f(CW\*(C`Apache2::Reload\*(C'\fR \f(CW\*(C`require()\*(C'\fRs such a
module all the global symbols end up in the \f(CW\*(C`Apache2::Reload\*(C'\fR
namespace!  So the module does get reloaded and you see the compile
time errors if there are any, but the symbols don't get imported to
the right namespace. Therefore the old version of the code is running.
.Sh "Failing to Find a File to Reload"
.IX Subsection "Failing to Find a File to Reload"
\&\f(CW\*(C`Apache2::Reload\*(C'\fR uses \f(CW%INC\fR to find the files on the filesystem. If
an entry for a certain filepath in \f(CW%INC\fR is relative,
\&\f(CW\*(C`Apache2::Reload\*(C'\fR will use \f(CW@INC\fR to try to resolve that relative
path. Now remember that mod_perl freezes the value of \f(CW@INC\fR at the
server startup, and you can modify it only for the duration of one
request when you need to load some module which is not in on of the
\&\f(CW@INC\fR directories. So a module gets loaded, and registered in
\&\f(CW%INC\fR with a relative path. Now when \f(CW\*(C`Apache2::Reload\*(C'\fR tries to find
that module to check whether it has been modified, it can't find since
its directory is not in \f(CW@INC\fR. So \f(CW\*(C`Apache2::Reload\*(C'\fR will silently
skip that module.
.PP
You can enable the \f(CW\*(C`Debug|/Debug\*(C'\fR mode to see what \f(CW\*(C`Apache2::Reload\*(C'\fR
does behind the scenes.
.Sh "Problems with Scripts Running with Registry Handlers that Cache the Code"
.IX Subsection "Problems with Scripts Running with Registry Handlers that Cache the Code"
The following problem is relevant only to registry handlers that cache
the compiled script. For example it concerns
\&\f(CW\*(C`ModPerl::Registry\*(C'\fR but not
\&\f(CW\*(C`ModPerl::PerlRun\*(C'\fR.
.PP
\fIThe Problem\fR
.IX Subsection "The Problem"
.PP
Let's say that there is a module \f(CW\*(C`My::Utils\*(C'\fR:
.PP
.Vb 8
\&  #file:My/Utils.pm
\&  #\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&  package My::Utils;
\&  BEGIN { warn _\|_PACKAGE_\|_ , " was reloaded\en" }
\&  use base qw(Exporter);
\&  @EXPORT = qw(colour);
\&  sub colour { "white" }
\&  1;
.Ve
.PP
And a registry script \fItest.pl\fR:
.PP
.Vb 5
\&  #file:test.pl
\&  #\-\-\-\-\-\-\-\-\-\-\-\-
\&  use My::Utils;
\&  print "Content\-type: text/plain\en\en";
\&  print "the color is " . colour();
.Ve
.PP
Assuming that the server is running in a single mode, we request the
script for the first time and we get the response:
.PP
.Vb 1
\&  the color is white
.Ve
.PP
Now we change \fIMy/Utils.pm\fR:
.PP
.Vb 2
\&  \-  sub colour { "white" }
\&  +  sub colour { "red" }
.Ve
.PP
And issue the request again. \f(CW\*(C`Apache2::Reload\*(C'\fR does its job and we can
see that \f(CW\*(C`My::Utils\*(C'\fR was reloaded (look in the \fIerror_log\fR
file). However the script still returns:
.PP
.Vb 1
\&  the color is white
.Ve
.PP
\fIThe Explanation\fR
.IX Subsection "The Explanation"
.PP
Even though \fIMy/Utils.pm\fR was reloaded, \f(CW\*(C`ModPerl::Registry\*(C'\fR's cached
code won't run '\f(CW\*(C`use My::Utils;\*(C'\fR' again (since it happens only once,
i.e. during the compile time). Therefore the script doesn't know that
the subroutine reference has been changed.
.PP
This is easy to verify. Let's change the script to be:
.PP
.Vb 8
\&  #file:test.pl
\&  #\-\-\-\-\-\-\-\-\-\-\-\-
\&  use My::Utils;
\&  print "Content\-type: text/plain\en\en";
\&  my $sub_int = \e&colour;
\&  my $sub_ext = \e&My::Utils::colour;
\&  print "int $sub_int\en";
\&  print "ext $sub_ext\en";
.Ve
.PP
Issue a request, you will see something similar to:
.PP
.Vb 2
\&  int CODE(0x8510af8)
\&  ext CODE(0x8510af8)
.Ve
.PP
As you can see both point to the same \s-1CODE\s0 reference (meaning that
it's the same symbol). After modifying \fIMy/Utils.pm\fR again:
.PP
.Vb 2
\&  \-  sub colour { "red" }
\&  +  sub colour { "blue" }
.Ve
.PP
and calling the script on the secondnd time, we get:
.PP
.Vb 2
\&  int CODE(0x8510af8)
\&  ext CODE(0x851112c)
.Ve
.PP
You can see that the internal \s-1CODE\s0 reference is not the same as the
external one.
.PP
\fIThe Solution\fR
.IX Subsection "The Solution"
.PP
There are two solutions to this problem:
.PP
Solution 1: replace \f(CW\*(C`use()\*(C'\fR with an explicit \f(CW\*(C`require()\*(C'\fR +
\&\f(CW\*(C`import()\*(C'\fR.
.PP
.Vb 2
\& \- use My::Utils;
\& + require My::Utils; My::Utils\->import();
.Ve
.PP
now the changed functions will be reimported on every request.
.PP
Solution 2: remember to touch the script itself every time you change
the module that it requires.
.SH "Threaded MPM and Multiple Perl Interpreters"
.IX Header "Threaded MPM and Multiple Perl Interpreters"
If you use \f(CW\*(C`Apache2::Reload\*(C'\fR with a threaded \s-1MPM\s0 and multiple Perl
interpreters, the modules will be reloaded by each interpreter as they
are used, not every interpreters at once.  Similar to mod_perl 1.0
where each child has its own Perl interpreter, the modules are
reloaded as each child is hit with a request.
.PP
If a module is loaded at startup, the syntax tree of each subroutine
is shared between interpreters (big win), but each subroutine has its
own padlist (where lexical my variables are stored).  Once
\&\f(CW\*(C`Apache2::Reload\*(C'\fR reloads a module, this sharing goes away and each
Perl interpreter will have its own copy of the syntax tree for the
reloaded subroutines.
.SH "Pseudo-hashes"
.IX Header "Pseudo-hashes"
The short summary of this is: Don't use pseudo-hashes. They are
deprecated since Perl 5.8 and are removed in 5.9.
.PP
Use an array with constant indexes. Its faster in the general case,
its more guaranteed, and generally, it works.
.PP
The long summary is that some work has been done to get this module
working with modules that use pseudo-hashes, but it's still broken in
the case of a single module that contains multiple packages that all
use pseudo-hashes.
.PP
So don't do that.
.SH "Copyright"
.IX Header "Copyright"
mod_perl 2.0 and its core modules are copyrighted under
The Apache Software License, Version 2.0.
.SH "Authors"
.IX Header "Authors"
Matt Sergeant, [e-mail]
.PP
Stas Bekman (porting to mod_perl 2.0)
.PP
A few concepts borrowed from \f(CW\*(C`Stonehenge::Reload\*(C'\fR by Randal Schwartz
and \f(CW\*(C`Apache::StatINC\*(C'\fR (mod_perl 1.x) by Doug MacEachern and Ask
Bjoern Hansen.