The continuing Stas / Nick discussion previously mentioned here should lead to an improvement of the perliol manpage.
Bu the main headline is that we had a long, heated discussion about ithreads, and how should one write a module that runs OK with a non-threaded perl, but at the same time is thread-friendly in an threaded environment.
Knowing that a pure-perl module is by default threadsafe, unless it relies on some external state, the problem was : how to detect that we run under a threaded perl, and if not, disable the thread-specific calls ? (Currently, use()'ing threads in a non-threaded perl emits a compile-time fatal error.)
Loading Config.pm is probably a bit overkill (esp. in mod_perl environments, as Elizabeth Mattijsen pointed out.) Nick Ing-Simmons suggested a new builtin ${^ITHREADS} (and I provided a patch for that). Sarathy quickly had the idea of a more generic bit-field variable ${^BUILD_OPTIONS} ; while Jarkko noticing "the lid of the worm can is flying in the air", Nicholas Clark put this idea to a new level, a special hash %{^BUILD_OPTIONS}. I have to quote Jarkko's reply :
I hereby suggest immediately forming a committee and at least three subcommittees to discuss which subset of %Config needs to be in the $^BUILDOPTIONS or %^BUILDOPTIONS or %^Config, since while some people might be happy with just, say, the $Config{use*}, some other people might want $Config{*size}, or $Config{*dir*}, or $Config{d_fork}, or $Config{extensions}, or ...Well. After having considered postponing RC2, Jarkko decided that this issue was not so important, especially with so little feedback from real module authors who write real-world thread-friendly code. So, when Arthur Bergman, the ithreads designer, returns from vacation, he'll decide if something has to be done for RC3.
