There's a bit more to it...

In mod_perl, scripts are loaded as subroutines. So all the scripts form a part of one larger, main script. That sounds somewhat dangerous, and it is.

You can imagine the big source to look a bit like:

sub script1 {
   # contents of script file 1 inserted here
   my $x;  # this is problematic in mod_perl...
   sub foo {
      # ...
   }
   foo();
}
sub script2 {
   # contents of script file 2 inserted here
   sub foo {
      # ...
   }
   foo();
}
[download]

Nested subs are somewhat problematic in Perl, in that they form a closure around the data the first time the outer sub is called. If there's a lexical variable ($x) that is used inside an inner sub, then the next time the lexical $x will see a different variable, but the inner sub will use the same variable it saw in the first invocation of the outer sub. So the nested sub foo will, after the first time, see a different $x than the top level sub script1 does. That's a major PITA, and, IMHO, not how it is supposed to be. But P5P seems reluctant to "fix" it, probably because it's very hard to fix (and to get it right).

Lesson to be learned: don't use top level lexicals in mod_perl. Use globals instead, but you best somehow restrict the effect of the scope to the script... I think local (and our or use vars, for strict) ought to do.

A second consequence is that if you edit a script, then in CGI it'll immediately be picked up by the webserver, but in mod_perl you have either restart the server, or find some other way to force it to reload the script from file — I think there are a few tricks to make that happen.

What you're talking about here is specific to the ModPerl::Registry module which is used for running CGI scripts under mod_perl. It does automatically pick up changes in your scripts. If you write an actual mod_perl module instead, you don't have to worry at all about it changing your code or creating nested subs.

The basic differences are the process model and the API. The process model for CGI is to fork a new perl interpreter every time a request comes in. For mod_perl, the interpreter is loaded into the web server process and stays there, which means there is no fork, and your scripts can stay in memory, and you can do things like keep database connections open to save time.

The other difference is the API. You have full access to the Apache API from mod_perl, which means you can do anything that other Apache modules in C can do: apply some filtering after a PHP script runs, use a custom data source for authentication, do a custom proxy to some internal server, etc.