On Tue, Jul 20, 2010 at 5:27 AM, Phillip Moore
<[email protected]> wrote:
> 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.
>
back in ms, did you also have perl5/<some-module>/ and
perl5/<some-module-threads>/ when necessary, to deal with the abi?
that seems... messy, as the project namespace gets polluted fast, and
it's not easy to see what threaded vs non-threaded modules are
available.
my first suggestion is to define a separate metaproject, say
perl5-threads/ and have the EFS::Perl::Depends code be configured to
search multiple metaprojects for modules. for example, a user wishing
to use Try-Tiny-0.06 in a piece of code using perl5threads/core would
write
#!/efs/dist/perl5-threads/5.10/.../bin/perl
# this isn't the real shebang, just clarifying user wants perl5-threads perl
use EFS::Perl::Depends qw( Try-Tiny/0.06 );
and the module would first search the perl5-threads/ metaproject, and
when Try-Tiny isn't found, search the perl5/ metaproject. this would
allow us to compile releases of perl5 modules only when required for
another metaproject. so, for example, Object-InsideOut-3.67 would be
compiled for both perl5-threads/ and perl5/.
#!/efs/dist/perl5-threads/5.10/.../bin/perl
use EFS::Perl::Depends qw(Object-InsideOut/3.67 );
would load perl5-threads/Object-InsideOut/3.67, since it's been
compiled in both metaprojects. if a specific metaproject is specified
in the EFS::Perl::Depends use statement, that mpr will be loaded no
matter what, so
use EFS::Perl::Depends qw( perl5/Object-InsideOut/3.67 );
will always load perl5's Object::InsideOut, even if the user is using
perl5-threads/core.
obviously, we'll have to determine at packaging time whether a module
needs to be packaged for multiple metaprojects, but i think that we
can build a couple small utilities to help us make that determination
(the simplest case being something that greps the tarball for
'threads' and lets the packager know to look more closely). we'll
also have to clearly document this, as well as exactly how
EFS::Perl::Depends is configured to search the metaproj namespaces,
and how that can be modified. also, we'll need to figure out how
EFS::Perl::Depends is found in the first place... is it packaged in
each perl5- metaproj? probably.
additionally, we might consider metaproj aliasing, so our metaproj
names may be more descriptive, and one is selected to be the default.
in this scenario, perl5/ could be a 'metaprojalias' to either
perl5-nonthreads/ or perl5-threads/ or some other perl5-
configuration.
i'm throwing a lot out here, but this is a large topic and full of
different levels of complexity. no doubt i've missed something here,
but there is no perfect solution, it's a matter of trade-offs.
thoughts?
~jerry
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
