Re: Disable lang/perl5 threads by default

[Jens Rehsack <sno%NetBSD.org@localhost>]

Am 03.06.2014 um 14:35 schrieb Greg Troxel <gdt%ir.bbn.com@localhost>:

> 
> Jonathan Perkin <jperkin%joyent.com@localhost> writes:
> 
>> For the last couple of releases, Perl has officially discouraged the
>> use of ithreads:
>> 
>>  
>> https://metacpan.org/changes/distribution/perl#Interpreter-based-threads-are-now-discouraged
>> 
>> Our options.mk enables threads by default if they are builtin, which
>> is probably the vast majority of platforms by now.
>> 
>> I propose we remove the PKG_SUGGESTED_OPTIONS setting, and leave it to
>> the user to enable them if required, so that we match the upstream
>> recommendation.
> 
> Do you know what will break/change if this is done?

DBD::Oracle usage for our perl will break. A lot of commercial software relying
on threads break (darkpan). Rjbs (current pumpkin) is currently on a road where
he's ignoring darkpan. I'm not sure whether I will follow this road.

> Absent a good argument, I think following upstream's recommendations is
> in order.

Generally yes, but in that case no. And it's not a depreciation - it's 
discouraged.

For the records: It's not recommended by perl people to "use threads" - but
only for 2 reasons:
1) using threads slows down the interpreter by 20%
2) using threads is ineffective because it uses a fork-simulation controlled by 
perl itself.

It is recommended because it's ineffective - not because it's broken. We 
(pkgsrc)
might try to follow the road of depending on packages + features - then I would
recommend turning of p5 threads by default. We can easily mark all packages 
requiring
threads using the feature notation then.

Further: I recommend to run "make test" in bulk-builds then to get quick 
feedback
about consequences when such changes are made (looks as if I actually 
collecting tuit's).

@Riba: Sounds as another C::AC check needed for D::O - have_threads :)

Cheers
-- 
Jens Rehsack
pkgsrc, Perl5
sno%NetBSD.org@localhost