in reply to Re^5: Perl calls C calls Perl CallBack: How Perl callback use the same interpreter/context as Perl caller?
in thread Perl calls C calls Perl CallBack: How Perl callback use the same interpreter/context as Perl caller?

Hi,

Perl_get_context() is returning NULL.

That leaves me with passing Perl interpreter pointer directly from Perl to C and then use it when calling the Perl callback, right?

Can you please give a hint of how should it be done?


Many thanks,

Itamar

  • Comment on Re^6: Perl calls C calls Perl CallBack: How Perl callback use the same interpreter/context as Perl caller?

Replies are listed 'Best First'.
Re^7: Perl calls C calls Perl CallBack: How Perl callback use the same interpreter/context as Perl caller?
by salva (Canon) on Jul 08, 2014 at 13:17 UTC
    You can find and example in the C function custom_cmp from the Sort::Packed module (https://metacpan.org/source/SALVA/Sort-Packed-0.08/Packed.xs).

    But passing the context around is done as an optimization in order to avoid calling Perl_get_context() repeatly. And it is not required unless the macro PERL_NO_GET_CONTEXT is defined. So, you are probably doing something on the wrong way.

    The first thing that chokes me is that if you start from the Perl side, you shouldn't be calling perl_alloc at all.

    Try remove any interpreter setup from your code, and calling some Perl function from the C side. It should just work.

[reply]
[d/l]
[select]

      Hi,

      This is the C code that called from a Perl function: (allocation, construction, etc. was used when I didn't attempt to use the Perl parser of the calling function)

          dTHX; // Returns NULL for my_perl :(

    // Call a PERL function
    dSP;                                                        /* Ini
+tialize stack pointer         */
    ENTER;                                                      /* Eve
+rything created after here    */
    SAVETMPS;                                                   /* ...
+is a temporary variable.      */
    PUSHMARK(SP);                                               /* Rem
+ember the stack pointer       */
    XPUSHs(sv_2mortal(newSViv((unsigned int)cbCtx)));           /* Pus
+h callback context onto stack */
    
    my_hash = newHV();
    my_arr  = newAV();

    hv_store( my_hash, "aaaaaa", 6, newSViv(42), 0 );

    for ( int i = 0; i < 50; i++ )
    {
        av_push( my_arr, newSViv((unsigned int)i) );
    }

    // Store reference to parameters on the HASH
    hv_store( my_hash, "bbbbbb", 6, newRV((SV*)my_arr), 0 );

    XPUSHs( sv_2mortal(newRV((SV*)my_hash)) );

    //PUTBACK;                                                  /* Mak
+e local stack pointer global  */
    call_pv( funcName, G_SCALAR );                              /* Cal
+l the function                */
    retVal = POPi;                                              /* POP
+ the return of the PERL function */
    SPAGAIN;                                                    /* Ref
+resh stack pointer            */
    PUTBACK;
    FREETMPS;                                                   /* fre
+e that return value           */
    LEAVE;                                                      /* ...
+and the XPUSHed "mortal" args */

      [download]
[reply]
[d/l]
        Under the hood, dTHX relies on Perl_get_context() to retrieve the context, so they are mostly equivalents.

        It occurs to me that it may be related to the way thread local storage (TLS) is managed on Windows, maybe it is not shared between DLLs.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom