perlhack.1

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

global variables in Perl start with \f(CW\*(C`PL_\*(C'\fR. This tells you whether the
current running program was created with the \f(CW\*(C`\-u\*(C'\fR flag to perl and then
\&\fIundump\fR, which means it's going to be false in any sane context.
.Sp
Line 4 calls a function in \fIperl.c\fR to allocate memory for a Perl
interpreter. It's quite a simple function, and the guts of it looks like
this:
.Sp
.Vb 1
\&    my_perl = (PerlInterpreter*)PerlMem_malloc(sizeof(PerlInterpreter));
.Ve
.Sp
Here you see an example of Perl's system abstraction, which we'll see
later: \f(CW\*(C`PerlMem_malloc\*(C'\fR is either your system's \f(CW\*(C`malloc\*(C'\fR, or Perl's
own \f(CW\*(C`malloc\*(C'\fR as defined in \fImalloc.c\fR if you selected that option at
configure time.
.Sp
Next, in line 7, we construct the interpreter; this sets up all the
special variables that Perl needs, the stacks, and so on.
.Sp
Now we pass Perl the command line options, and tell it to go:
.Sp
.Vb 4
\&    exitstatus = perl_parse(my_perl, xs_init, argc, argv, (char **)NULL);
\&    if (!exitstatus) {
\&        exitstatus = perl_run(my_perl);
\&    }
.Ve
.Sp
\&\f(CW\*(C`perl_parse\*(C'\fR is actually a wrapper around \f(CW\*(C`S_parse_body\*(C'\fR, as defined
in \fIperl.c\fR, which processes the command line options, sets up any
statically linked \s-1XS\s0 modules, opens the program and calls \f(CW\*(C`yyparse\*(C'\fR to
parse it.
.IP "Parsing" 3
.IX Item "Parsing"
The aim of this stage is to take the Perl source, and turn it into an op
tree. We'll see what one of those looks like later. Strictly speaking,
there's three things going on here.
.Sp
\&\f(CW\*(C`yyparse\*(C'\fR, the parser, lives in \fIperly.c\fR, although you're better off
reading the original \s-1YACC\s0 input in \fIperly.y\fR. (Yes, Virginia, there
\&\fBis\fR a \s-1YACC\s0 grammar for Perl!) The job of the parser is to take your
code and \*(L"understand\*(R" it, splitting it into sentences, deciding which
operands go with which operators and so on.
.Sp
The parser is nobly assisted by the lexer, which chunks up your input
into tokens, and decides what type of thing each token is: a variable
name, an operator, a bareword, a subroutine, a core function, and so on.
The main point of entry to the lexer is \f(CW\*(C`yylex\*(C'\fR, and that and its
associated routines can be found in \fItoke.c\fR. Perl isn't much like
other computer languages; it's highly context sensitive at times, it can
be tricky to work out what sort of token something is, or where a token
ends. As such, there's a lot of interplay between the tokeniser and the
parser, which can get pretty frightening if you're not used to it.
.Sp
As the parser understands a Perl program, it builds up a tree of
operations for the interpreter to perform during execution. The routines
which construct and link together the various operations are to be found
in \fIop.c\fR, and will be examined later.
.IP "Optimization" 3
.IX Item "Optimization"
Now the parsing stage is complete, and the finished tree represents
the operations that the Perl interpreter needs to perform to execute our
program. Next, Perl does a dry run over the tree looking for
optimisations: constant expressions such as \f(CW\*(C`3 + 4\*(C'\fR will be computed
now, and the optimizer will also see if any multiple operations can be
replaced with a single one. For instance, to fetch the variable \f(CW$foo\fR,
instead of grabbing the glob \f(CW*foo\fR and looking at the scalar
component, the optimizer fiddles the op tree to use a function which
directly looks up the scalar in question. The main optimizer is \f(CW\*(C`peep\*(C'\fR
in \fIop.c\fR, and many ops have their own optimizing functions.
.IP "Running" 3
.IX Item "Running"
Now we're finally ready to go: we have compiled Perl byte code, and all
that's left to do is run it. The actual execution is done by the
\&\f(CW\*(C`runops_standard\*(C'\fR function in \fIrun.c\fR; more specifically, it's done by
these three innocent looking lines:
.Sp
.Vb 3
\&    while ((PL_op = CALL_FPTR(PL_op\->op_ppaddr)(aTHX))) {
\&        PERL_ASYNC_CHECK();
\&    }
.Ve
.Sp
You may be more comfortable with the Perl version of that:
.Sp
.Vb 1
\&    PERL_ASYNC_CHECK() while $Perl::op = &{$Perl::op\->{function}};
.Ve
.Sp
Well, maybe not. Anyway, each op contains a function pointer, which
stipulates the function which will actually carry out the operation.
This function will return the next op in the sequence \- this allows for
things like \f(CW\*(C`if\*(C'\fR which choose the next op dynamically at run time.
The \f(CW\*(C`PERL_ASYNC_CHECK\*(C'\fR makes sure that things like signals interrupt
execution if required.
.Sp
The actual functions called are known as \s-1PP\s0 code, and they're spread
between four files: \fIpp_hot.c\fR contains the \*(L"hot\*(R" code, which is most
often used and highly optimized, \fIpp_sys.c\fR contains all the
system-specific functions, \fIpp_ctl.c\fR contains the functions which
implement control structures (\f(CW\*(C`if\*(C'\fR, \f(CW\*(C`while\*(C'\fR and the like) and \fIpp.c\fR
contains everything else. These are, if you like, the C code for Perl's
built-in functions and operators.
.Sp
Note that each \f(CW\*(C`pp_\*(C'\fR function is expected to return a pointer to the next
op. Calls to perl subs (and eval blocks) are handled within the same
runops loop, and do not consume extra space on the C stack. For example,
\&\f(CW\*(C`pp_entersub\*(C'\fR and \f(CW\*(C`pp_entertry\*(C'\fR just push a \f(CW\*(C`CxSUB\*(C'\fR or \f(CW\*(C`CxEVAL\*(C'\fR block
struct onto the context stack which contain the address of the op
following the sub call or eval. They then return the first op of that sub
or eval block, and so execution continues of that sub or block.  Later, a
\&\f(CW\*(C`pp_leavesub\*(C'\fR or \f(CW\*(C`pp_leavetry\*(C'\fR op pops the \f(CW\*(C`CxSUB\*(C'\fR or \f(CW\*(C`CxEVAL\*(C'\fR,
retrieves the return op from it, and returns it.
.IP "Exception handing" 3
.IX Item "Exception handing"
Perl's exception handing (i.e. \f(CW\*(C`die\*(C'\fR etc.) is built on top of the low-level
\&\f(CW\*(C`setjmp()\*(C'\fR/\f(CW\*(C`longjmp()\*(C'\fR C\-library functions. These basically provide a
way to capture the current \s-1PC\s0 and \s-1SP\s0 registers and later restore them; i.e.
a \f(CW\*(C`longjmp()\*(C'\fR continues at the point in code where a previous \f(CW\*(C`setjmp()\*(C'\fR
was done, with anything further up on the C stack being lost. This is why
code should always save values using \f(CW\*(C`SAVE_FOO\*(C'\fR rather than in auto
variables.
.Sp
The perl core wraps \f(CW\*(C`setjmp()\*(C'\fR etc in the macros \f(CW\*(C`JMPENV_PUSH\*(C'\fR and
\&\f(CW\*(C`JMPENV_JUMP\*(C'\fR. The basic rule of perl exceptions is that \f(CW\*(C`exit\*(C'\fR, and
\&\f(CW\*(C`die\*(C'\fR (in the absence of \f(CW\*(C`eval\*(C'\fR) perform a \f(CWJMPENV_JUMP(2)\fR, while
\&\f(CW\*(C`die\*(C'\fR within \f(CW\*(C`eval\*(C'\fR does a \f(CWJMPENV_JUMP(3)\fR.
.Sp
At entry points to perl, such as \f(CW\*(C`perl_parse()\*(C'\fR, \f(CW\*(C`perl_run()\*(C'\fR and
\&\f(CW\*(C`call_sv(cv, G_EVAL)\*(C'\fR each does a \f(CW\*(C`JMPENV_PUSH\*(C'\fR, then enter a runops
loop or whatever, and handle possible exception returns. For a 2 return,
final cleanup is performed, such as popping stacks and calling \f(CW\*(C`CHECK\*(C'\fR or
\&\f(CW\*(C`END\*(C'\fR blocks. Amongst other things, this is how scope cleanup still
occurs during an \f(CW\*(C`exit\*(C'\fR.
.Sp
If a \f(CW\*(C`die\*(C'\fR can find a \f(CW\*(C`CxEVAL\*(C'\fR block on the context stack, then the
stack is popped to that level and the return op in that block is assigned
to \f(CW\*(C`PL_restartop\*(C'\fR; then a \f(CWJMPENV_JUMP(3)\fR is performed.  This normally
passes control back to the guard. In the case of \f(CW\*(C`perl_run\*(C'\fR and
\&\f(CW\*(C`call_sv\*(C'\fR, a non-null \f(CW\*(C`PL_restartop\*(C'\fR triggers re-entry to the runops
loop. The is the normal way that \f(CW\*(C`die\*(C'\fR or \f(CW\*(C`croak\*(C'\fR is handled within an
\&\f(CW\*(C`eval\*(C'\fR.
.Sp
Sometimes ops are executed within an inner runops loop, such as tie, sort
or overload code. In this case, something like
.Sp
.Vb 1
\&    sub FETCH { eval { die } }
.Ve
.Sp
would cause a longjmp right back to the guard in \f(CW\*(C`perl_run\*(C'\fR, popping both
runops loops, which is clearly incorrect. One way to avoid this is for the
tie code to do a \f(CW\*(C`JMPENV_PUSH\*(C'\fR before executing \f(CW\*(C`FETCH\*(C'\fR in the inner
runops loop, but for efficiency reasons, perl in fact just sets a flag,
using \f(CW\*(C`CATCH_SET(TRUE)\*(C'\fR. The \f(CW\*(C`pp_require\*(C'\fR, \f(CW\*(C`pp_entereval\*(C'\fR and
\&\f(CW\*(C`pp_entertry\*(C'\fR ops check this flag, and if true, they call \f(CW\*(C`docatch\*(C'\fR,
which does a \f(CW\*(C`JMPENV_PUSH\*(C'\fR and starts a new runops level to execute the
code, rather than doing it on the current loop.
.Sp
As a further optimisation, on exit from the eval block in the \f(CW\*(C`FETCH\*(C'\fR,
execution of the code following the block is still carried on in the inner
loop.  When an exception is raised, \f(CW\*(C`docatch\*(C'\fR compares the \f(CW\*(C`JMPENV\*(C'\fR
level of the \f(CW\*(C`CxEVAL\*(C'\fR with \f(CW\*(C`PL_top_env\*(C'\fR and if they differ, just
re-throws the exception. In this way any inner loops get popped.
.Sp
Here's an example.
.Sp
.Vb 5
\&    1: eval { tie @a, \*(AqA\*(Aq };
\&    2: sub A::TIEARRAY {
\&    3:     eval { die };
\&    4:     die;
\&    5: }
.Ve
.Sp
To run this code, \f(CW\*(C`perl_run\*(C'\fR is called, which does a \f(CW\*(C`JMPENV_PUSH\*(C'\fR then
enters a runops loop. This loop executes the eval and tie ops on line 1,
with the eval pushing a \f(CW\*(C`CxEVAL\*(C'\fR onto the context stack.
.Sp
The \f(CW\*(C`pp_tie\*(C'\fR does a \f(CW\*(C`CATCH_SET(TRUE)\*(C'\fR, then starts a second runops loop
to execute the body of \f(CW\*(C`TIEARRAY\*(C'\fR. When it executes the entertry op on
line 3, \f(CW\*(C`CATCH_GET\*(C'\fR is true, so \f(CW\*(C`pp_entertry\*(C'\fR calls \f(CW\*(C`docatch\*(C'\fR which
does a \f(CW\*(C`JMPENV_PUSH\*(C'\fR and starts a third runops loop, which then executes
the die op. At this point the C call stack looks like this:
.Sp
.Vb 10
\&    Perl_pp_die
\&    Perl_runops      # third loop
\&    S_docatch_body
\&    S_docatch
\&    Perl_pp_entertry
\&    Perl_runops      # second loop
\&    S_call_body
\&    Perl_call_sv
\&    Perl_pp_tie
\&    Perl_runops      # first loop
\&    S_run_body
\&    perl_run
\&    main
.Ve
.Sp
and the context and data stacks, as shown by \f(CW\*(C`\-Dstv\*(C'\fR, look like:
.Sp
.Vb 9
\&    STACK 0: MAIN
\&      CX 0: BLOCK  =>
\&      CX 1: EVAL   => AV()  PV("A"\e0)
\&      retop=leave
\&    STACK 1: MAGIC
\&      CX 0: SUB    =>
\&      retop=(null)
\&      CX 1: EVAL   => *
\&    retop=nextstate
.Ve
.Sp
The die pops the first \f(CW\*(C`CxEVAL\*(C'\fR off the context stack, sets
\&\f(CW\*(C`PL_restartop\*(C'\fR from it, does a \f(CWJMPENV_JUMP(3)\fR, and control returns to
the top \f(CW\*(C`docatch\*(C'\fR. This then starts another third-level runops level,
which executes the nextstate, pushmark and die ops on line 4. At the point
that the second \f(CW\*(C`pp_die\*(C'\fR is called, the C call stack looks exactly like
that above, even though we are no longer within an inner eval; this is
because of the optimization mentioned earlier. However, the context stack
now looks like this, ie with the top CxEVAL popped:
.Sp
.Vb 7
\&    STACK 0: MAIN
\&      CX 0: BLOCK  =>
\&      CX 1: EVAL   => AV()  PV("A"\e0)
\&      retop=leave
\&    STACK 1: MAGIC
\&      CX 0: SUB    =>
\&      retop=(null)
.Ve
.Sp
The die on line 4 pops the context stack back down to the CxEVAL, leaving
it as:
.Sp
.Vb 2
\&    STACK 0: MAIN
\&      CX 0: BLOCK  =>
.Ve
.Sp
As usual, \f(CW\*(C`PL_restartop\*(C'\fR is extracted from the \f(CW\*(C`CxEVAL\*(C'\fR, and a
\&\f(CWJMPENV_JUMP(3)\fR done, which pops the C stack back to the docatch:
.Sp
.Vb 10
\&    S_docatch
\&    Perl_pp_entertry
\&    Perl_runops      # second loop
\&    S_call_body
\&    Perl_call_sv
\&    Perl_pp_tie
\&    Perl_runops      # first loop
\&    S_run_body
\&    perl_run
\&    main
.Ve
.Sp
In  this case, because the \f(CW\*(C`JMPENV\*(C'\fR level recorded in the \f(CW\*(C`CxEVAL\*(C'\fR
differs from the current one, \f(CW\*(C`docatch\*(C'\fR just does a \f(CWJMPENV_JUMP(3)\fR
and the C stack unwinds to:
.Sp
.Vb 2
\&    perl_run
\&    main
.Ve
.Sp
Because \f(CW\*(C`PL_restartop\*(C'\fR is non-null, \f(CW\*(C`run_body\*(C'\fR starts a new runops loop
and execution continues.
.Sh "Internal Variable Types"
.IX Subsection "Internal Variable Types"
You should by now have had a look at perlguts, which tells you about
Perl's internal variable types: SVs, HVs, AVs and the rest. If not, do
that now.
.PP
These variables are used not only to represent Perl-space variables, but
also any constants in the code, as well as some structures completely
internal to Perl. The symbol table, for instance, is an ordinary Perl
hash. Your code is represented by an \s-1SV\s0 as it's read into the parser;
any program files you call are opened via ordinary Perl filehandles, and
so on.
.PP
The core Devel::Peek module lets us examine SVs from a
Perl program. Let's see, for instance, how Perl treats the constant
\&\f(CW"hello"\fR.
.PP
.Vb 7
\&      % perl \-MDevel::Peek \-e \*(AqDump("hello")\*(Aq
\&    1 SV = PV(0xa041450) at 0xa04ecbc
\&    2   REFCNT = 1
\&    3   FLAGS = (POK,READONLY,pPOK)