johannz has asked for the wisdom of the Perl Monks concerning the following question:

As the title says, are there issues running Parse::RecDescent under mod_perl?

I googled for this and only found one place that mentions there being issues and that was a presentation by a perlmonk, juerd. His presentation is at http://juerd.nl/files/slides/2004dpw/en/slides.html.

In it, he says that:

#  Special variables: NEVER use $`, $& and $'
# Or modules that use them

    * Text::Balanced
    * Parse::RecDescent
    * re (use re 'debug' is not lexical!)
    * and more... 

But I couldn't find any other references on Google to people having issues running RecDescent under Mod_perl. In fact, the stuff I found implied that people were runnning it successfully. Including links I found here in the monastary, Running Parse::RecDescent Under mod_perl

I don't want to go through the effort of writing my code using Parse::RecDescent if it will not work under mod_perl, but my confidence in being able to use them together is shaken by my research. So, any thoughts?

  • Comment on Are there issues running Parse::RecDescent under Mod_Perl?

Replies are listed 'Best First'.
Re: Are there issues running Parse::RecDescent under Mod_Perl?
by Juerd (Abbot) on Feb 14, 2006 at 23:39 UTC

    But I couldn't find any other references on Google to people having issues running RecDescent under Mod_perl.

    Read the documentation for Devel::SawAmpersand. This provides you with the necessary information that the slides without narration do not.

    The problem with mod_perl is that the perl interpreter is re-used for subsequent requests. Everything that is global, is still around after the document has been served to the browser.

    Parse::RecDescent will work, and not slower than you're used to, but there may be a significant slowdown for other scripts. To solve this, consider running a dedicated Apache httpd for the P::RD script, or factoring the parsing out of Apache (fork, or communicate with a daemon).

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Re: Are there issues running Parse::RecDescent under Mod_Perl?
by bart (Canon) on Feb 14, 2006 at 16:12 UTC
    I don't want to go through the effort of writing my code using Parse::RecDescent if it will not work under mod_perl
    I'd go the other way, any code using Parse::RecDescent is going to be slow anyway, so I'd just run this as a CGI script. The slightly slower startup time (around 1/2 second, that's my first guess) is not something that'll hurt you much, in this case. After all, scripts under modperl do not run any faster at all!

      he slightly slower startup time (around 1/2 second, that's my first guess) is not something that'll hurt you much, in this case.

      Whether that is a problem, depends on a lot of things. There is no way for you or me, or the OP even, to know for sure that it will not hurt.

      After all, scripts under modperl do not run any faster at all!

      Compared to what, exactly?

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

        Compared to what, exactly?
        Compared to non-modperl (thus, CGI).

        Modperl speeds up the initialization phase of CGI-like scripts, so as a result a script responds faster. But the body of the script will not run faster at all.

Re: Are there issues running Parse::RecDescent under Mod_Perl?
by ikegami (Patriarch) on Feb 14, 2006 at 18:28 UTC

    That's interesting; Parse::RecDescent does indeed use $&.

    The problem is not that it won't run in mod_perl, that problem is that using $& can slow down Perl scripts. More specifically, using $& (or its friends) anywhere in a Perl script will cause all regexps with no captures to run slower than normal. In mod_perl, this would apply to all scripts running in a given mod_perl process.