Re: Getting a / when regex should produce nothing

Thank you, AW, for a well-written summary of the aspect of
mod_perl that causes the most difficult/nasty bugs for people.
But you left out one important caveat which could scare away
more potential users than it saves.

The retention of values from previous executions applies
only to global variables.  Specifically:

>   - when the script terminates, whatever is in the *global*  
> variables stays there.

>    it remembers your compiled script, and the state of its *global*  
> variables from the last execution

>    The big danger is that your *global* variables start with the  
> state in which the previous run


Programming pundits have been discouraging the use of global
variables for years now, perhaps a little more strongly than
is good for the state of the art.  However anyone feels
about that, it's useful to write out some guidelines:

* Use global variables for information that you specifically
   want to save across executions.  The best case is for items
   that are defined during the first execution, then used in
   later executions.

* If you want to use a global variable for some other reason,
   be very careful and aware that it may start an execution
   with a value from a previous execution.

* Put most variables inside of subs (including handlers).
   These will be initialized for each execution just as in
   other perl contexts.  Most people have come to accept a bit
   more parameter-passing to subs than would be necessary with
   global variables, for this initialization plus avoiding
   inadvertent bugs when one forgets a global variable name.

A technique that I've used to avoid problems (particularly
when converting old CGI scripts) is, given a list of global
variables at the start of the module:

my ($var1, $var2, $other_var);
my $inited_var = 123;

write directly thereafter:

sub init_vars {
     undef $var1; undef $var2; undef $other_var;
     inited_var = 123;
}

and call init_vars just before each exit from each handler.
Even easier though to me less satisfying, call init_vars right
after entry to each handler.

Regards,
cmac

On Apr 26, 2010, at 4:23 AM, André Warnier wrote:

> 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.
>