Conclusion

Every Perl script is different (except plaigarized ones!), but we've looked at some general guidelines for common traps and hangups many coders run into attempting to write or migrate script to the mod_perl environment. It may seem like a lot of work, but in most cases the mod_perl constraints result in better coding practice, and a deeper understanding of Perl -- which must be worth something! Remember though that mod_perl is not literally about functionality, but optimization -- if modifying large, hairy existing scripts seems unrealistic, it might be worth considering whether to use mod_perl at all for those scripts.

In a worst case scenario, if you simply cannot modify an old or beastly script to work properly in the mod_perl fantasy bubble world, all efficiency is not lost. One simple change to your Apache httpd.conf can salvage the effort -- to some extent. Change the line

PerlHandler Apache::Registry

to:

PerlHandler Apache::PerlRun

The above change will abandon the use of mod_perl fantasy bubble world, and simply execute your Perl scripts the old-fashioned way, with the exception being that the interpreter is still built into the web server and therefore doesn't need to be launched as a separate process. You certainly lose many optimization possibilities in resorting to the PerlRun module, but in some cases any execution is better than none. Again, this is really a last resort option, and is only a small improvement over not using mod_perl at all.

Additional Resources

• The mod_perl Guide by Stas Bekman is a most thorough exploration of mod_perl.
• mod_perl_traps is a concise and clear summary of many issues we've seen this month.
  Compilation Amnesia
  The Perl You Need to Know
  The Perl You Need to Know Special: Introduction to mod_perl Part 3