in reply to Win32 unthreaded perl builds: To USE_MULTI or not ?

MULTIPLICITY—what USE_MULTI sets—allows multiple interpreters to exist in the same process.[1]

This is required to support threads (including the fork emulation on Windows). It's also required to embed multiple instances of the Perl interpreter into a (non-Perl) program.

Feel free to build without MULTIPLICITY if you don't need those things. It heard it gives a 10% performance boost.

I don't know what PERL_IMPLICIT_SYS—what USE_IMP_SYS sets—does, so I can't help there.

  1. It does this by moving all globals into a struct, and by passing a pointer to this struct to every API function. Effectively, it makes an object (in the OOP sense of the word) of the Perl interpreter.

Replies are listed 'Best First'.
Re^2: Win32 unthreaded perl builds: To USE_MULTI or not ?
by syphilis (Archbishop) on Jul 31, 2025 at 03:48 UTC
    Thank you to all respondents. (I have enough trouble keeping track of just one perl instance per process ;-)
    Seems that USE_MULTI and USE_IMP_SYS have to match - either both defined or both undefined.

    I don't really use an unthreaded build all that much, as I like to stay in sync with the configuration used by the broad population.
    But, as someone who uses neither fork() nor threads, it would probably the "right" configuration for me (if it really mattered).
    Hence, I like to keep checking that the capacity to build an unthreaded perl on Windows doesn't get lost.

    The first thing one finds out pretty quickly on an unthreaded Windows build, is that running cpan Some::Module fails to succeed - and that's the case irrespective of the status of USE_IMP_SYS/USE_MULTI.
    That failure occurs because the cpan utility does a fork() during the "make test" stage.
    There's a bug report from 3 years ago about this at https://rt.cpan.org/Ticket/Display.html?id=143500. Maybe that bug report should be copied onto the github repo, though I doubt that would make much difference.
    Anyway ... it's pretty simple just to run cpan -T App::cpanminus (which skips "make test") and then use cpanm to install modules.

    For now, at least, I'll just keep building the unthreaded builds the same way that I always have (with USE_IMP_SYS and USE_MULTI undefined).

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

      Seems that USE_MULTI and USE_IMP_SYS have to match - either both defined or both undefined.

      Not quite. Both USE_IMP_SYS and USE_ITHREADS require USE_MULTI, but not the other way around. USE_MULTI can be used without either of the other two.

[reply]
[d/l]
[select]
        Not quite.

        Yes, you're right. Thanks for correcting.
        I had tested for USE_ITHREADS=undef USE_MULTI=define USE_IMP_SYS=undef and found it to fail.
        However, I'm now finding that configuration to work fine - so the original test was obviously not done correctly.

        From memory, that original test that I did failed in exactly the same way as USE_ITHREADS=undef USE_MULTI=undef USE_IMP_SYS=define !!
        (I wonder what could possibly have gone wrong ;-)

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

In Section Seekers of Perl Wisdom