Use a Perl_Interpreter and NOT call it my_perl? Use TWO interpreters?

[Torsten Mohr]

Hi,

there are examples available on how to allocate a Perl_Interpreter
in a C program and work with it, e.g. let it execute a script.

In these examples, the Perl_Interpreter is always called
my_perl and i noticed that compiling fails when it is given
a different name.

Is it possible to give it a different name?

Is it possible to allovate TWO Perl_Interpreters at a time
and let them execute code?


Best regards,
Torsten.

 

[Matt Garrish]

I'm not sure shat "work" means.

If you'd like, I can give you all sorts of examples of shat work and shat
jobs I've had.... (sorry, I just couldn't pass that one up... : )

Matt

 

[Gregory Toomey]

Hi,

there are examples available

Where? If we can't see code we can't comment

on how to allocate a Perl_Interpreter

DO you mean fork a process?

in a C program and work with it, e.g. let it execute a script.

I'm not sure shat "work" means.

In these examples, the Perl_Interpreter is always called
my_perl and i noticed that compiling fails when it is given
a different name.

If you are just forking a subprocess, you can fork as many as you want.
if you want to call executables different names you can do that too.

Is it possible to give it a different name?

Is it possible to allovate TWO Perl_Interpreters at a time
and let them execute code?


Best regards,
Torsten.

Your question is too cryptic. Be specific.

gtoomey

 

[Torsten Mohr]

Hi,

Where? If we can't see code we can't comment

ok, you're right here. Maybe it is a bit misleading what
i describe. I'll try again:

In a self-written C program (not a script) i can do something like:

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

static Perl_Interpreter* my_perl;

in main() i can then do:

my_perl = perl_alloc();
perl_construct(my_perl);

A full example is "miniperlmain.c" in the official Perl
source tree.

There, a "Perl_Interpreter" is allocated and used.
Several macros are also used. When i now try to
do the same in an own program and i call the
"Perl_Interpreter" NOT "my_perl", the program
simply does not compile. I wonder if there's a
reason for this.

Also, i wonder if it is somehow still possible to
use TWO instances of "Perl_Interpreter".

I don't want to fork a subprocess or use threads in
the perl script itself, i'd like to use TWO instances
of Perl_Interpreter.

I hope this description makes it a bit clearer.


Thanks for any hints,
Torsten.

 

[Dave Weaver]

Also, i wonder if it is somehow still possible to
use TWO instances of "Perl_Interpreter".

I don't want to fork a subprocess or use threads in
the perl script itself, i'd like to use TWO instances
of Perl_Interpreter.

Looks like "my_perl" is hard-coded into perl.h

I got around this problem using C++ by having a class to represent
the Perl interpreter with a member variable called my_perl:

class Perl {

public:
Perl();
~Perl();

// ...

private:
PerlInterpreter *my_perl;
};

Perl:erl() {
my_perl = perl_alloc();
if (my_perl != NULL) {
perl_construct(my_perl);
char *dummy_argv[] = { "", "-e", "0" };
perl_parse(my_perl, NULL, 3, dummy_argv, NULL);
}
}

Perl::~Perl() {
perl_destruct(my_perl);
perl_free(my_perl);
}

Don't know if you can come up with a similar work-around for C
though.

Cheers,
Dave.

 

[Martien Verbruggen]

Hi,

there are examples available on how to allocate a Perl_Interpreter
in a C program and work with it, e.g. let it execute a script.

In these examples, the Perl_Interpreter is always called
my_perl and i noticed that compiling fails when it is given
a different name.

Is it possible to give it a different name?

Yes.

$ cat interp.c
#include <EXTERN.h>
#include <perl.h>

int
main(int argc, char **argv, char **env)
{
PerlInterpreter *your_perl;
int exitstatus;

your_perl = perl_alloc();
if (!your_perl)
exit(1);
perl_construct(your_perl);

exitstatus = perl_parse(your_perl, NULL, argc, argv, (char **)NULL);
if (!exitstatus) {
exitstatus = perl_run(your_perl);
}

perl_destruct(your_perl);
perl_free(your_perl);

return exitstatus;
}

$ gcc -c `/opt/perl-5.8.2/bin/perl -MExtUtils::Embed -e ccopts` interp.c
$ gcc interp.o `/opt/perl-5.8.2/bin/perl -MExtUtils::Embed -e ldopts`
$ ./a.out -e 'print "Hello World!\n"'
Hello World!
$

The above also works when you make your_perl a static variable, declared
outside of main, or a global variable declared outside of main.

Is it possible to allovate TWO Perl_Interpreters at a time
and let them execute code?

$ cat interp.c
#include <EXTERN.h>
#include <perl.h>

#define MAX_PERLS 4

int
main(int argc, char **argv, char **env)
{
PerlInterpreter *your_perl[MAX_PERLS];
int i;

for (i = 0; i < MAX_PERLS; i++)
{
your_perl = perl_alloc();
if (!your_perl)
exit(1);
perl_construct(your_perl);
}

for (i = 0; i < MAX_PERLS; i++)
{
perl_parse(your_perl, NULL, argc, argv, (char **)NULL);
perl_run(your_perl);
}

for (i = 0; i < MAX_PERLS; i++)
{
perl_destruct(your_perl);
perl_free(your_perl);
}

return 0;
}

$ gcc -c `/opt/perl-5.8.2/bin/perl -MExtUtils::Embed -e ccopts` interp.c
$ gcc interp.o `/opt/perl-5.8.2/bin/perl -MExtUtils::Embed -e ldopts`
$ ./a.out -e 'print "Hello World!\n"'
Hello World!
Hello World!
Hello World!
Hello World!
$

Martien

 

[Martien Verbruggen]

Looks like "my_perl" is hard-coded into perl.h

Only in the pTHX and aTHX macros, and then only when threads are
enabled. You can get along without them. See the perlguts documentation
for why pTHX and aTHX exist. It's unlikely that the OP needs them, and
more likely that the OP should avoid them.

OP: read perlembed and perlguts, entirely, until it makes sense.
Reading perlapi also helps in understanding the way Perl works in C
code.

You could also consider getting "Extending and Embedding Perl", by Tim
Jenness and Simon Cozens.

Martien