Problem when embedding 2 Perl interpreters in C++

Discussion in 'Perl Misc' started by ritesh, Jul 11, 2006.

  1. ritesh

    ritesh Guest

    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
    ritesh, Jul 11, 2006
    #1
    1. Advertising

  2. ritesh

    ritesh Guest

    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
    ritesh, Jul 11, 2006
    #2
    1. Advertising

  3. 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
    Stephan Titard, Jul 12, 2006
    #3
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David F. Skoll
    Replies:
    2
    Views:
    856
    David F. Skoll
    Nov 14, 2003
  2. Craig Ringer
    Replies:
    1
    Views:
    391
    Mustafa Demirhan
    Nov 18, 2004
  3. Replies:
    3
    Views:
    308
  4. Yash
    Replies:
    3
    Views:
    111
    Peter Scott
    Jul 14, 2004
  5. Garthy

    Embedding multiple interpreters

    Garthy, Dec 6, 2013, in forum: Python
    Replies:
    14
    Views:
    104
    Garthy
    Dec 7, 2013
Loading...

Share This Page