in reply to perl interpreter must be named my_perl?

Yes, from looking at perl.h, the aTHX macro (and many other macros) hardcode my_perl as the variable name of the Perl interpreter. I think this is mostly so you don't have to pass that variable as a parameter everywhere.

Looking at perlembed, I don't find this requirement mentioned, so a bug report to document that seems plausible.

Allowing to change the name of that variable would increase the complexity of the macros and the usage I think, so this would be a lot of work for little gain. But the documentation should be explicit about this.

Replies are listed 'Best First'.
Re^2: perl interpreter must be named my_perl?
by Anonymous Monk on Nov 30, 2023 at 08:56 UTC

    Allowing to change the name of that variable would increase the complexity of the macros and the usage I think, so this would be a lot of work for little gain. But the documentation should be explicit about this.

    But on the section of "Maintaining multiple interpreter instances", Below code （different name) could be built and runs well.( the author cleverly avoid all macros which include my_perl) 
    #include <EXTERN.h>
#include <perl.h>

/* we're going to embed two interpreters */

#define SAY_HELLO "-e", "print qq(Hi, I'm $^X\n)"

int main(int argc, char **argv, char **env)
{
    PerlInterpreter *one_perl, *two_perl;
    char *one_args[] = { "one_perl", SAY_HELLO, NULL };
    char *two_args[] = { "two_perl", SAY_HELLO, NULL };

    PERL_SYS_INIT3(&argc,&argv,&env);
    one_perl = perl_alloc();
    two_perl = perl_alloc();

    PERL_SET_CONTEXT(one_perl);
    perl_construct(one_perl);
    PERL_SET_CONTEXT(two_perl);
    perl_construct(two_perl);

    PERL_SET_CONTEXT(one_perl);
    perl_parse(one_perl, NULL, 3, one_args, (char **)NULL);
    PERL_SET_CONTEXT(two_perl);
    perl_parse(two_perl, NULL, 3, two_args, (char **)NULL);

    PERL_SET_CONTEXT(one_perl);
    perl_run(one_perl);
    PERL_SET_CONTEXT(two_perl);
    perl_run(two_perl);

    PERL_SET_CONTEXT(one_perl);
    perl_destruct(one_perl);
    PERL_SET_CONTEXT(two_perl);
    perl_destruct(two_perl);

    PERL_SET_CONTEXT(one_perl);
    perl_free(one_perl);
    PERL_SET_CONTEXT(two_perl);
    perl_free(two_perl);
    PERL_SYS_TERM();
    exit(EXIT_SUCCESS);
}

    [download]
[reply]
[d/l]

      Yeah - if you want to use a different variable name, you have to avoid all the macros. I'm not sure if there is a simple way to recognize all those macros (beyond running the compiler). As aTHX and aTHX_ are known, then likely any macro that contains THX (the thread handle, if Perl is compiled with threads, empty otherwise) should be avoided...

[reply]
[d/l]
[select]

        No, that's all wrong. The THX macros don't care about the name of the "top-level" variable.

        aTHX should only be used in a function which either has pTHX in its parameter list or in which dTHX; is used. In a MULTIPLICITY build, aTHX will only access the parameter var named my_perl created by pTHX or the local var named my_perl created by dTHX. In other words, it only accesses the my_perl variable the THX macros create themselves.

        In a non-MULTIPLICITY build, those macros are all undefined. They don't mention my_perl at all.

        So either way, they don't care about the name of the name of the "top-level" variable.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom