in reply to Significance of #define PERL_NO_GET_CONTEXT in XS

PERL_NO_GET_CONTEXT makes your XS code more efficient on threaded perls, but you then have to write your XS code in such a way as to work with it.

On threaded (or more accurately, MULTIPLICITY) perls, all the interpreter state is collected into a single structure which is accessed via the my_perl local var; so for example you have 

#define PL_stack_sp my_perl->Istack_sp

[download]
Under MULTIPLICITY, most perl API functions take an extra initial my_perl argument, which you have to provide. Within perl core itself, this is handled by the pTHX and aTHX macros, which declare the extra arg, and pass that arg down to lower-level functions.

However, if your caller didn't provide my_perl, you have to retrieve it yourself, e.g. from thread-local storage (which may be relatively slow). In the absence of PERL_NO_GET_CONTEXT, every API function call is defined in such a way that it does the (slow) retrieve of my_perl before calling that function. So it takes care of the details for you, but slowly.

See Background and PERL_IMPLICIT_CONTEXT for more info.

Dave.

Replies are listed 'Best First'.
Re^2: Significance of #define PERL_GET_NO_CONTEXT in XS
by halfcountplus (Hermit) on Mar 13, 2014 at 18:08 UTC

    Thanks Dave. Thus far I've ignored the stuff in guts beyond XSUBS. Anyway, the dTHX option seems to be working out.

[reply]
[d/l]
Re^2: Significance of #define PERL_GET_NO_CONTEXT in XS
by syphilis (Archbishop) on Mar 14, 2014 at 03:20 UTC
    I take it there's no point in defining PERL_GET_NO_CONTEXT if MULTIPLICITY is not defined, and one could therefore do: 
    #ifdef MULTIPLICITY
#define PERL_GET_NO_CONTEXT 1
#endif

    [download]
    Would that ensure that PERL_GET_NO_CONTEXT gets defined whenever (and only whenever) it's relevant ?

    Update: Heh ... for one thing, MULTIPLICITY is not defined prior to the inclusion of the standard XS headers, so we can't use that.
    I guess we can have the Makefile pass another symbol (iff $Config{usemultiplicity} is 'define').
    Or just define PERL_GET_NO_CONTEXT, and not concern ourselves with whether perl was even built with "usemultiplicity".

    Cheers,
    Rob
[reply]
[d/l]
      Or just define PERL_GET_NO_CONTEXT, and not concern ourselves with whether perl was even built with "usemultiplicity"
      That's the thing to do. On unthreaded builds etc, the macros will all just Do The Right Thing (which is usually to do nothing).

      To further elaborate, consider the following snippet of XS code: 

      #define PERL_NO_GET_CONTEXT
sv_foo(a, b, c);

      [download]
      On a threaded/MULTIPLICITY build, it would macro-expand to: 
      Perl_sv_foo(my_perl, a, b, c);

      [download]
      Remove the PERL_NO_GET_CONTEXT and, depending on platform (this is Linux), it might expand to something like: 
      Perl_sv_foo(((PerlInterpreter *)pthread_getspecific(PL_thr_key)),
    a, b, c);

      [download]

      On a non-threaded build, it would expand to the following, regardless of whether PERL_NO_GET_CONTEXT is present: 

      Perl_sv_foo(a, b, c);

      [download]

      The dTHX macro basically expands to 

      PerlInterpreter * my_perl =
    (PerlInterpreter *)pthread_getspecific(PL_thr_key);

      [download]
      So it's more efficient to just calculate my_perl once per function rather than for every function call, but it's even better to get your caller to pass it to you. So declare your functions as say Foo(pTHX_ int a, int b) and call them as Foo(aTHX_ 1, 2);

      Dave.

[reply]
[d/l]
[select]
        Ok ... I'll just make it a blanket "#define PERL_NO_GET_CONTEXT" ... no ifs and buts ;-)

        I mainly use Inline::C to autogenerate my XS files.
        The appealing aspect of using dTHX is that Inline::C already accommodates that approach. That is, this simple Inline::C demo works fine: 
        use strict;
use warnings;

use Inline C => Config =>
  BUILD_NOISY => 1,
  PRE_HEAD => "#define PERL_NO_GET_CONTEXT",
  ;

use Inline C => <<'EOC';

SV * dubble(SV * in) {
 dTHX;
 return newSViv(SvIV(in) * 2);
}

EOC

my $x = dubble(23);
print $x; # 46

        [download]
        But handling pTHX_ and aTHX_ is way beyond Inline's current capabilities, and the XS file therefore needs to be written by hand.

        I'm not even sure what the XS file should look like when we use pTHX_ and aTHX_. The following seems to work: 
        #define PERL_NO_GET_CONTEXT

#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

SV * dubble(pTHX_ SV * in) {
 return newSViv(SvIV(in) * 2);
}

MODULE = FOO    PACKAGE = FOO    

SV *
dubble (in)
    SV *    in
CODE:
  RETVAL = dubble(aTHX_ in);
OUTPUT:
  RETVAL

        [download]
        But I wouldn't like to guarantee that it's not doing something wrong and/or unnecessary.
        The example in the docs to which you linked, invokes a wrapper function called my_xsub - but I've written it so that dubble() wraps itself.
        Is that a valid technique ? Is there something better ?

        Thanks Dave. Good question halfcountplus.

        Cheers,
        Rob
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom