Re^2: perl interpreter must be named my

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]

Comment on Re^2: perl interpreter must be named my_perl? Download Code

Replies are listed 'Best First'.
Re^3: perl interpreter must be named my_perl? by Corion (Patriarch) on Nov 30, 2023 at 09:05 UTC
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]
Re^4: perl interpreter must be named my_perl? by ikegami (Patriarch) on Dec 01, 2023 at 03:49 UTC
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]
Re^5: perl interpreter must be named my_perl? by Anonymous Monk on Dec 01, 2023 at 05:33 UTC
In a non-MULTIPLICITY build, those macros are all undefined. They don't mention my_perl But MULTIPLICITY is the de facto default build option, Am I right?	[reply]
Re^6: perl interpreter must be named my_perl? by ikegami (Patriarch) on Dec 01, 2023 at 19:22 UTC
Re^6: perl interpreter must be named my_perl? by bliako (Abbot) on Dec 01, 2023 at 08:05 UTC
Re^7: perl interpreter must be named my_perl? by etj (Priest) on Jan 08, 2025 at 23:39 UTC