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.

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?

Just to be clear, I said the global my_perl isn't used by the THX macros with or without MUTLIPLICITY.

As for MULTIPLICITY being the default? No. It's is off by default.

MULTIPLICITY is what allows a process to have multiple interpreters. A build with thread support requires MULTIPLICITY since each thread has its own interpreter. So MULTIPLICITY is automatically defined when a building Perl with thread support.

A build without thread support usually won't use MULTIPLICITY. If the OP's program only needs one interpreter, they should use a build of Perl that was built without MULTIPLICITY (for a performance boost).

I would avoid words like "de facto, default" and just do my own checks:

linux perlbrew:

perl -V | grep -i multi
      usemultiplicity=undef
[download]

linux system perl:

    usemultiplicity=define
Compile-time options:
    ...
    MULTIPLICITY
[download]

I liked Multiplicity - what the heck is it?

bw, bliako