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

I am looking for an example of maintaining a persistent pool of Perl interpreters for use from my C program (a daemon that accepts web services requests that it sometimes fulfills using calls to Perl modules/providers). I've looked through the mod_perl docs, but am a bit overwhelmed and as far as I can tell it seems to maintain a single interpreter per Apache process. If anyone has any advice or a pointer to examples, it will be greatly appreciated.
  • Comment on Maintaining a pool of Perl interpreters

Replies are listed 'Best First'.
Re: Maintaining a pool of Perl interpreters
by stvn (Monsignor) on Jan 02, 2005 at 21:22 UTC
    I've looked through the mod_perl source code, but am a bit overwhelmed and as far as I can tell it seems to maintain a single interpreter per Apache process.

    As far as I know mod_perl 1.0 did maintain a single perl interpreter per Apache process. So you are unlikely to find anything in that source code.

    However mod_perl 2.0 has a number of options for how your perl interpreters are managed, I am a little fuzzy on the details of that, but you might try checking the mod_perl site for more info, and maybe looking over the mod_perl 2.0 source code as well. You could also try asking your question on the mod_perl dev list, Stas (the guy running the mod_perl 2.0 project) is a really nice guy, and may be able to point you in a good direction.

    -stvn
Re: Maintaining a pool of Perl interpreters
by Aristotle (Chancellor) on Jan 02, 2005 at 22:36 UTC

    Have you seen PPerl? You can probably just use it directly, no need to write any code yourself.

    Makeshifts last the longest.

Re: Maintaining a pool of Perl interpreters
by mpeters (Chaplain) on Jan 02, 2005 at 22:46 UTC
    You might be able to do the same thing by using apache/mod_perl and your own custom C code. You could write the primary handler in C. If the request meets the requirements that your application has for using the Perl providers then you could perform an internal redirect to the Perl handler, get the results and then return that to the user.

    This would, in my mind, simply your code greatly. You would no longer have to worry about handling multiple connections, logging, etc. You would also not have to worry about a pool of persistent Perl interpreters since your pool of apache children would be a pool of Perl interpreters.
Re: Maintaining a pool of Perl interpreters
by beauregard (Monk) on Jan 02, 2005 at 23:20 UTC
    When I started looking for perl_clone() example code, I ran across intpools.c in the Sendmail::Milter module. Mind you, last updated in 2002 so it's not the most up-to-date...

    c.

Re: Maintaining a pool of Perl interpreters
by PodMaster (Abbot) on Jan 03, 2005 at 02:19 UTC
    `perldoc perlembed'

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      You can also use SpeedyCGI, which does almost the same thing you want to do. http://www.daemoninc.com/SpeedyCGI/
Re: Maintaining a pool of Perl interpreters
by Courage (Parson) on Jan 03, 2005 at 02:11 UTC
    I applause you for asking a question on C level, also I applause you for asking same question on p5p list.

    Some people here afraid of postng to p5p, I do not know why. it's a shame you have some knowledge and share it on PM but refuse sharing this on p5p. But this happens, and, unfortunately, quite not rare case btw,,,

    Sorry for not giving you good answer for question, may be I'll do it tomorrow
    (feel free to '--' me for just applausing and not giving answers... what do you expect rfom stupid dog?)

    Best regards,
    Courage, the Cowardly Dog

Re: Maintaining a pool of Perl interpreters
by zentara (Cardinal) on Jan 03, 2005 at 14:16 UTC
    Don't overlook FastCGI, it maintains a set of Perl interpreters for each script, setup in a configuration file. FCGI

    I'm not really a human, but I play one on earth. flash japh