There's not much reason to define USE_MULTI without USE_ITHREADS. It might be useful for embedding, if you want to manage multiple interpreters, but I wouldn't be too surprised if that broke.
USE_IMP_SYS might also be useful when embedded since it does nearly all file handling via callbacks (see iperlsys.h) which you can override if you want to virtualize access to the filesystem. There's little need for that for non-threaded and non-embedded perl though. This is used to maintain per-pseudo-process environment variables and current directories for pseudo-fork.
| [reply] |
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.
- 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.
| [reply]
[d/l]
[select] |
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] |
| [reply]
[d/l]
[select] |
What do USE_MULTI and USE_IMP_SYS bring to an unthreaded perl?
Are you sure you'll never need the fork emulation?
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
| [reply]
[d/l]
[select] |