perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Getting a / when regex should produce nothing
Date Mon, 26 Apr 2010 11:23:30 GMT
Chris Bennett wrote:
...
> 
> I have not regretted it. I have learned many details that I could have 
> overlooked with regular perl. Mod_perl is more unforgiving of not 
> knowing exactly what my variables are doing and what values they hold
> 
Perl and nod_perl are very deterministic, and there is no mystery in 
what they do with variables.  The trick is to understand exactly how 
mod_perl works, and how this plays along with the way Apache (in its 
different MPM variations) works.

> This particular issue has taught me two things.
> I am never going to use no warnings 'uninitialized' again. It is too 
> dangerous to be overlooking possible problems.
I agree.
Maybe even do as Michael said, and make all warnings fatal, if we are 
talking about user/web oriented applications.

> It has also taught me that perl itself may leave values in variables 
> such as $1, even after a server stop and start and first running of a 
> program.
That however, is definitely not the case.
If you stop and start the server, you have a totally new environment, 
and there is nothing left from the previous one.
If you are using a "prefork" version of the Apache server, then that is 
also true each time an Apache child ends and a new one is started : it 
gets a "new perl" and a new set of variables.
(but the thing is, you mostly cannot predict when Apache will start a 
new child, nor which child will handle which request).
For other Apache configurations, the situation may be a bit more 
complicated.

The main aspect to understand with mod_perl (as opposed to running a 
perl program without it) :
- when you run a perl script without mod_perl, the sequence is :
   - a new perl interpreter is started, clean
   - your script gets compiled, and gets a brand-new set of variables
   - your script gets run, starting with this new set of variables
   - your script "exits"
   - perl exits, and returns all its memory to the OS
  .. and the next time you run your script, the same steps happen.

under mod_perl :
   - an Apache child starts, and it gets a new perl
   - your script gets compiled, the first time around. That time, it 
gets a brand-new set of variables.
   - your script gets run, the first time, with these brand-new variables.
   - when the script terminates, whatever is in these variables stays 
there.
   - the perl interpreter inside that same Apache child stays alive, amd 
it "remembers" the compiled code of your script.

Now is the difference : when a new request comes into Apache, and (as 
may happen) it is sent to the *same* Apache child, it is processed by 
the same perl interpreter.  And that one is not "clean" : it remembers 
your compiled script, and the state of its variables from the last 
execution.  And that is where it starts from.
The big gain is that perl does not have to compile the script again, it 
can run the compiled code right away.
The big danger is that your variables start with the state in which the 
previous run of the same script in the same Apache child left them.
That can sometimes be put to good use, but it is also deadly if you are 
not very careful.

The above is only a very approximative explanation, and the reality is 
somewhat subtler.  But if you stick to that basic explanation, you will 
avoid much trouble.

The fact that your $1 variable retained a value from an earlier 
comparison however has nothing to do with the above.  That would be true 
even if your script was not running under mod_perl.

  Sounds like an early lesson out of C. Never assume anything is
> in fact defined without defining it yourself.
That is a good principle in general (and not only in perl).


A final observation : at the beginning, I think what most perl/web 
programmers find the most interesting aspect of mod_perl is that 
scripts/modules run much faster (because they do not need to be 
re-compiled each time).
But I find that the real benefit is more in terms of how closely it is 
integrated into the Apache "insides", and the incredible power it gives 
you to create "handlers" and "filters" to let you intervene at just 
about every stage of the processing of a request, and use all the power 
and flexibility of perl (and of the CPAN library) to do all kinds of 
stuff you could not even dream of otherwise.
reading the on-line mod_perl documentation is also a unique way to learn 
how Apache itself works.



Mime
View raw message