I recently stopped building perl with threads support, based largely on Jerry's feedback that the perl community as a whole would prefer people not use the threads support.
Well, that might end up being an expensive decision, and here's why. If we end up with a request from our users for a threads-enabled perl. we can always create a special build for them (say, in perl5/core-threads, or something similar). However, as soon as you do that, in all likely hood many of the existing compiled XS modules will NOT work with both builds of perl5. That is, if you have perl5/core/5.10.1 and perl5/core-threads/5.10.1, then modules compiled with one may not work (perhaps at all) with the other. That means you have introduced a new binary ABI, and that means you have to introduce two "compiler" definitions for perl 5.10.1, and build everything for 5.10 twice. This what we had to do back at MS, for perl5.6. We had both "5.6" and "5.6-threads" in the namespace, next to 5.004, 5.005 and 5.005-threads, too. I originally kept the builds separate, since I found that the perl benchmark suite ran 20% slower across the board when threads were enabled. While I have not personally done the benchmarks, I recall reading somewhere that this performance penalty was addressed in 5.8 and beyond. Therefore, in order to simplify the way we build perl modules, I only wanted ONE build of each core release, and ONE ABI to worry about. Therefore, I built perl5/core with threads by default. This raises and interesting issue, and shows how limited, in practice, sharing of binaries in EFS will be. We have to make these decisions based on what will work for OUR users and OUR user community. Other sites may very well want to make different decisions, and thus will want different builds of perl and friends. I think we need to give this decision some more thought. I am very concerned about the cost of maintaining both non-threaded and threaded perl in EFS. Sadly, I knew who used the threads API at MS; I have no idea who may or may not be using it here, and trying to gather that information will be exceptionally difficult. We can post a messages to the efsperl mailing list (which has seen no traffic in over a year), but we can't count on the responses being a representative statistical sampling of our user community. Bear in mind that for perl5.10, in /efs/dist/perl5, we already built with threads, so we can't really implement this internally until we deploy 5.12 or later releases. IOW, we're stuck with perl5.10 with threads internally.
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
