The Perl You Need to Know Special: Introduction to mod_perl Part 2
May 15, 2000
|
Last month we took a magical journey to the land of mod_perl, an
idyllic paradise where the penalties of executing interpreted Perl
code are greatly minimized. In that article, we focused on the
exciting relationship between the
Apache web server and the
mod_perl module,
and how this relationship optimizes execution
of
Perl
by reducing forking and caching pre-compiled code within
Apache child processes. This month, we shift our attention more
towards actual code, and some ways in which your Perl code may
need to be adapted to function properly within the environment
created by mod_perl.
|
A Warm Familiar Place
When your Perl scripts are executed within a mod_perl environment,
it is as if they are contained within a soothing and comfortable
bubble. This bubble is like a microcosm of the "real world",
in this case the real world being the operating system environment
where Perl scripts are normally executed. Think of the mod_perl
bubble like one of those miniature villages captured inside a glass
ball which you can shake to cause a snowstorm or an earthquake. Life
in this bubble is familiar and most things happen as they should --
but this bubble is not really the outside world, and there
are some differences.
Like the terms "Xerox" and "Kleenex", the term
"CGI" has come to be overextended to all server-side
scripts that relate to the web server and browser. Technically,
though, mod_perl scripts are not
CGI scripts. However,
because the CGI technology has come to define how we relate
to parameters between the web server and our scripts, including
such famous examples as Perl's
CGI.pm module, we generally continue to use the CGI model
and vocabulary in talking about mod_perl. And we continue to use
CGI.pm, for instance, to manipulate form and state parameters sent
from the web browser. All of this assumes you are using CGI.pm
version of at least 2.36 and Perl 5.004+. It is still worth
understanding, though, that mod_perl is in effect emulating
the CGI environment for our convenience.
In a "real" operating system environment, Perl scripts
are by default executed within the package named "main",
assuming you have not declared otherwise. We haven't yet discussed
packages in the
Perl You Need to Know series, but you can think of a package
as a namespace, or a context. So, you can have a subroutine or
variable named PEPSI in package "blue" which
will be independent of a subroutine or variable named PEPSI in
package "red". This matters in mod_perl because Perl
scripts do not run within the package "main" -- rather,
they run within a uniquely named package based upon the URI of the
web server resource. If you are familiar with packages, this
information alone will be important. If you're thinking
"so?", we'll see two important reasons this package stuff
matters and the solutions over the next few pages.
Scripts are advised against using exit() calls, which are not
supported by mod_perl, which prefers the Apache::exit() call.
That said, there is a safety net in place and existing exit()
calls will be intercepted and passed to the Apache exit routine.
Because the mod_perl bubble is such a familiar environment, many
Perl scripts do not require modification to run under mod_perl.
However, there are some significant cases of handling variables
and subroutines where you may need to modify your Perl scripts to
behave properly within the familiar yet sometimes strange bubble
world of mod_perl.
Contents:
My() Troubles
Repackage Your Way to Success
Compilation Amnesia
Conclusion
Take Home Message: Optimizations
The Perl You Need to Know
My() Troubles
|
