Problem when embedding 2 Perl interpreters in C++

R

ritesh

Hi,

I'm facing a problem when embedding two perl interpreters in my C++
code.

My code has 2 threads - the GUI and the Core thread. The core thread
initializes a Perl interpreter and all works fine here. Both the
threads communicate via Events.

In a particular scenario the GUI thread, invokes a function which
further invokes a perl subroutine using the "perl_call_argv" call.
Since the GUI thread dosen't have a perl interpreter running on it
there are 2 options I have -

1. Use the PERL_SET_CONTEXT macro within the function that the GUI
thread calls, and then invoke the perl subroutine using the
"perl_call_argv" call. -- This works fine.

However I'm not sure if two threads should be sharing the same perl
interpreter. The Core thread might also make some calls to
"perl_call_argv" while the GUI thread is working. Would the
interpreter be intelligent enough to handle 2 threads? I found a
negative answer to this question at this link -
modperlbookDOTorg/html/ch24_03DOThtml
The text explicity states --> "This of course requires that each Perl
interpreter instance is accessed
by only one thread at any given time."

2. In second scenario, I create a new perl interpreter within the
function the GUI thread calls. Creation and destruction of the
interpreter happens within this function, since the interpreter is not
required by the GUI thread after the function returns. Here is the
function -

void function_for_gui_thread(char * perlFnToCall)
{
PL_perl_destruct_level = 1; /* keep setting this value to 1
before construction and destruction of the interperator for gui thread
*/

PerlInterpreter * guiPerlInterp = 0; /* this is the interp i
create within the function for GUI thread */
perlInterp = perl_alloc();
PERL_SET_CONTEXT(guiPerlInterp);
perl_construct(guiPerlInterp);
PL_perl_destruct_level = 1;
perl_run(guiPerlInterp);


char ** perl_args = (char**)sgMalloc(2*sizeof(char*));
perl_args[0] = "";
perl_args[1] = 0;
perl_call_argv(perlFnToCall, G_DISCARD, perl_args); /* for
simplicity I've added the perlFnToCall variable in the function
parameters, however it is determined in this function at runtime */
sgFree(perl_args);


PL_perl_destruct_level = 1;
perl_destruct(guiPerlInterp);
PL_perl_destruct_level = 1;
perl_free(guiPerlInterp);
PERL_SET_CONTEXT(corePerlInterpreter); /* corePerlInterpreter
is the interp initialized by the core thread */
}

Note that I set the context of the interpretor to the new guiPerlInterp
before I start using it. When exiting the function I set the context
back to corePerlInterpreter.

First question that comes to my mind is - Do I really need to set the
context back to corePerlInterpreter for the GUI thread, since it
dosen't need a perl interpreter after this function call?

Second when I run the program, the perl subroutine is invoked (i've
verified this using print commands), then within the perl subroutine
certain subroutines are invoked which use Perl XS routines. When the
control reaches the first such subroutine I get an error like this -

Usage : getReport(reportName)

and the program exits. The "getReport(reportName)" is the XS function
that the perl function invokes.

------------------------------------

Could you please help me out with this. The program works fine when I
use the first scenario. However I would like to use the second
scenario.

Thanks,
ritesh
 
R

ritesh

One point that I missed out -

Right now I'm not sure if the perl I have on my system is compiled
using the options -
-Dusethreads -Duseithreads

Could this be the reason that the second scenario is giving these
"Usage : ..." errors?

Thanks,
ritesh
 
S

Stephan Titard

ritesh escribió:
Hi,

I'm facing a problem when embedding two perl interpreters in my C++
code.

My code has 2 threads - the GUI and the Core thread. The core thread
initializes a Perl interpreter and all works fine here. Both the
threads communicate via Events.

In a particular scenario the GUI thread, invokes a function which
further invokes a perl subroutine using the "perl_call_argv" call.
Since the GUI thread dosen't have a perl interpreter running on it
there are 2 options I have -

1. Use the PERL_SET_CONTEXT macro within the function that the GUI
thread calls, and then invoke the perl subroutine using the
"perl_call_argv" call. -- This works fine.

However I'm not sure if two threads should be sharing the same perl
interpreter.
I believe not.

The Core thread might also make some calls to
"perl_call_argv" while the GUI thread is working. Would the
interpreter be intelligent enough to handle 2 threads? I found a
negative answer to this question at this link -
modperlbookDOTorg/html/ch24_03DOThtml
The text explicity states --> "This of course requires that each Perl
interpreter instance is accessed
by only one thread at any given time." that makes sense to me

2. In second scenario, I create a new perl interpreter within the
function the GUI thread calls. Creation and destruction of the
interpreter happens within this function, since the interpreter is not
required by the GUI thread after the function returns. Here is the
function -

void function_for_gui_thread(char * perlFnToCall)
{
PL_perl_destruct_level = 1; /* keep setting this value to 1
before construction and destruction of the interperator for gui thread
*/

PerlInterpreter * guiPerlInterp = 0; /* this is the interp i
create within the function for GUI thread */
perlInterp = perl_alloc();
PERL_SET_CONTEXT(guiPerlInterp);
perl_construct(guiPerlInterp);
PL_perl_destruct_level = 1;
perl_run(guiPerlInterp);


char ** perl_args = (char**)sgMalloc(2*sizeof(char*));
perl_args[0] = "";
perl_args[1] = 0;
perl_call_argv(perlFnToCall, G_DISCARD, perl_args); /* for
simplicity I've added the perlFnToCall variable in the function
parameters, however it is determined in this function at runtime */
sgFree(perl_args);


PL_perl_destruct_level = 1;
perl_destruct(guiPerlInterp);
PL_perl_destruct_level = 1;
perl_free(guiPerlInterp);
PERL_SET_CONTEXT(corePerlInterpreter); /* corePerlInterpreter
is the interp initialized by the core thread */
}

Note that I set the context of the interpretor to the new guiPerlInterp
before I start using it. When exiting the function I set the context
back to corePerlInterpreter.

First question that comes to my mind is - Do I really need to set the
context back to corePerlInterpreter for the GUI thread, since it
dosen't need a perl interpreter after this function call?

Second when I run the program, the perl subroutine is invoked (i've
verified this using print commands), then within the perl subroutine
certain subroutines are invoked which use Perl XS routines. When the
control reaches the first such subroutine I get an error like this -

Usage : getReport(reportName)

and the program exits. The "getReport(reportName)" is the XS function
that the perl function invokes.

------------------------------------

Could you please help me out with this. The program works fine when I
use the first scenario. However I would like to use the second
scenario.

Thanks,
ritesh
if you don'use dynamic loading (dlopen and such) you already pay the
price of loading the perl library...
in that case maybe you could start the perl interpreter from the main
program (thread) and mutex the calls to it from any thread (GUI or other...)

sorry I cannot help more on this, I haven't hooked perl into C++
maybe you could post this on p5p, if nobody else answers

hth
--stephan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,995
Messages
2,570,226
Members
46,815
Latest member
treekmostly22

Latest Threads

Top