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
|
Similar Threads
