Question

I have a web application that uses a parser created with Parse::RecDescent. A parser object is needed in several parts of the application and since the parser takes quite a bit of memory I have up to now treated the parser object as a singleton. This works well in a pure CGI environment since only one expression is parsed by the same object at one time. I am however unsure if this will still work when running in an environment where the same object parser is parsing more than one string at the time.

For instance if I try to run the application under FastCGI can it it become a problem if two request at the same time use the same parser object to parse to different strings?

If I need to I can change the application so that the parser is no longer a singleton, however I would prefer not as the current solution is simpler.

Answer 1

To the best of my knowledge, FastCGI doesn’t use Perl threads but processes. Thus, you should be safe.

Furthermore, if you are using Perl threads and Parse::RecDescent, you’re likely never using the same object to parse different things concurrently. Pseudocode:

use threads;
use Parse::RecDescent;
our $SingletonRD = Parse::RecDescent->new($grammar);

my @threads = map {threads->new(\&thread_loop)} (1..5);

sub thread_loop {
    $SingletonRD->parse($text);
}

This is an example where the threads are created after the singleton. Here’s what happens:

• You create the singleton object and store it in $SingletonRD.
• You create (in a loop) five threads. When spawning a new thread, perl does
  • create a copy of the global symbol table. That includes all package variables and subroutines.
  • create a copy of the various perl-interpreter internal data structures (except the OP tree).

This effectively clones $SingletonRD one time for each thread. No memory saved. Now, if you were to set up the parser only after creating threads, the variables wouldn’t be shared between them to begin with, so no memory saving and no thread-unsafety here either.

In principle, you can use threads::shared to share data between threads. But that doesn’t (easily) work on objects and complicated nested structures. Therefore, this will likely be out of the question for Parse::RecDescent parsers.

PS: Have a look at Parse::Yapp or better yet, Parse::Eyapp. They’re much, much faster (algorithmically) than Parse::RecDescent and I’d intuitively say they are even likely to use less memory.