The mod_perl site

What is mod_perl?

Have a look at the user docs for 1.0 to start expecially the 'Coding guidelines' and 'Frequent mod_perl problems' sections.

The mod_perl documentation is amongst the best open source documentation on the web. It is well worth a read.

In a nutshell if you program like this it will generally work:

#!/usr/bin/perl -w
use strict;
use Module qw( do_stuff );
my $var = ....
do_stuff($var);
exit 0;
[download]

The easiest way to mod perl is use strict and put all your functions into modules and have very simple scripts. In essence mod perl wraps your script into a subroutine that gets called over and over. That means that global vars do not get reset between calls to the script {now effectively a sub in the long running mod_perl 'script'} so you can have persistent DBH on the one side and unexpected bugs on the other. If you localise with my and Modularise the problems will mostly vanish. # you don't put subs in a mod perl script..... # unless you want lots of warnings.... # /o will bite you too.

It runs a lot deeper than that when you start hacking the api.

mod_perl can be much more than just a CGI accelerator. The mod_perl API gives you access to the various phases of the Apache request cycle as well as some of the internals of Apache itself. Using mod_perl "handlers" you can program in a way totally different from regular "CGI scripts", and more akin to Java servlets. Of course the deeper you get the more of your foot/leg/lower-portion-of-body you can shot off if you are not careful. But as they say "with great power comes great responsibility". If you are really interested, I would recommend the O'Reilly Eagle book, it gives a better "tutorial" style introduction than the online docs IMHO, and then the Mod Perl Cookbook if you really wanna get into it.

I mention this because seeing "mod_perl" in a job opening may mean this kind of mod_perl and not just "running CGI scripts in the mod_perl environment". They are really 2 different worlds (again IMO).

Good luck.