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.
Breaking news from p5p 0 Comments More | Login | Reply /