perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Re-using tipools outside mod_perl / apache
Date Tue, 04 Jan 2005 19:21:59 GMT
Jeremy Redburn wrote:
> Hello,
> I've been looking for advice (perlmonks, p5p, colleagues) on maintaining 
> a persistent pool of Perl interpreters, and all the advice seems to come 
> back to mod_perl 2. While I was hoping to find a simpler example, it 
> seems I will need to make my way through your codebase.
> I was hoping some of you might have some advice in terms of decoupling 
> the tipool and interpreters work from apache and mod_perl itself so that 
> it can be used on its own. Even better would be a simple reduced case 
> used to test the interpreters pool.

Jeremy you can find a simple case of having two interpreters (w/o using 
our code) below [1]

> Any advice will be greatly appreciated.

Doing that should be as simple as taking the code in
and using it where you need it. (I think you may need to get some structs 
from modperl_types.h). You can see examples on how it's used by grepping 
for functions in the other files under src/modules/perl

Feel free to ask any questions if you have after you've looked at the 
code. Make sure to get the latest svn:

> ps. If anyone is interested, this work is part of some work I'm doing 
> with the Pegasus CIMOM ( Pegasus as it stands allows 
> you to write providers in C and C++. I have enabled Perl support, but it 
> requires a lock on the Perl interpreter while in use and is thus not all 
> that useful. I'm looking to implement a pool of Perl interpreters so as 
> to enable external callbacks to the system from the Perl providers and 
> multiple calls to Perl providers simultaneously.

I'm planning to restart soon my work on DBI::Pool so some of the concepts 
might be re-used there, but since DBI::Pool will manage connection pools 
it'll not involve perl internally, the users will provide the interpreters 
(e.g. ithreads).

[1] this is just a test program I've used to reproduce some problem in 
perl note that it doesn't do cloning and no context switching. see [2] 
below for another program that does do that

/* pool.c */

#include <EXTERN.h>
#include <perl.h>

  * gcc -o pool pool.c `perl  -MExtUtils::Embed -e ccopts -e ldopts` -Wall -g

int main()
     char *argv[] = {"perl", "-e", "warn", NULL};
     int argc = 3;

     PerlInterpreter *my_perl1 = perl_alloc();
     PerlInterpreter *my_perl2;
     SV *sv;

     perl_parse(my_perl1, NULL, argc, argv, 0);
     sv = Perl_newSVpv(my_perl1, "foo", 3);

     my_perl2 = perl_alloc();
     perl_parse(my_perl2, NULL, argc, argv, 0);

     Perl_sv_free(my_perl2, sv);



     return 0;

[2] this one does a proper context switching:

/* clone.c */
#include <EXTERN.h>
#include <perl.h>

  * gcc -o clone clone.c `perl -MExtUtils::Embed -e ccopts -e ldopts` -Wall -g

#define TEST "sub foo {}"

int main(int argc, char **argv, char **env)
      char *embedding[] = { "", "-le", "0" };
      PerlInterpreter *my_perl = perl_alloc();
      PerlInterpreter *perl2;


      perl_parse(my_perl, NULL, 3, embedding, (char **)NULL);

      Perl_eval_pv(my_perl, TEST, TRUE); /* loaded only by the first perl */

      perl2 = perl_clone(my_perl, CLONEf_KEEP_PTR_TABLE);




Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message