develooper Front page | perl.perl5.porters | Postings from April 2018

Re: [perl #133021] Removed the word "discouraged" from threads'documentation

Thread Previous | Thread Next
From:
Karl Williamson
Date:
April 1, 2018 15:34
Subject:
Re: [perl #133021] Removed the word "discouraged" from threads'documentation
Message ID:
1faeb065-fd19-8ccc-621c-44061d73788e@khwilliamson.com
On 03/29/2018 02:46 PM, Aristotle Pagaltzis wrote:
> * E. Choroba <perlbug-followup@perl.org> [2018-03-25 21:31]:
>> See also #125106, which seems to lead nowhere, maybe because it was
>> too ambitious. This patch provides just the minimal change.
> 
> The minimal change would be to simply remove the sentence, and that is
> what I would favour to begin with.
> 
> 
> * Christian Walde <walde.christian@gmail.com> [2018-03-26 12:49]:
>> Since this change doesn't have a ticket attached to it, i figured it
>> would be useful to provide the context of what led to its creation.
> 
> Thank you. I vaguely remembered having been a part of that discussion
> and am glad to have the context back; I am also relieved to see that my
> current position is close to my previous stance.
> 
>> This discouragement was introduced by rjbs in commit
>> 10a4597703f4b044d3f968bf3923644ea2387f5c. I've extracted some of the
>> chat log that led to it.
> 
> I regret not catching this at the time, but the reason given for calling
> the feature discouraged does not meet the technical definition of the
> term in perlpolicy. So the statement in the threads.pm POD is simply not
> true.
> 
> I must admit my own anti-ithreads bias here, and that this is probably
> what led me to skip over that issue. I am not unhappy to see threads
> discouraged-in-the-colloquial-sense and have always avoided them myself
> (with success).
> 
> However, for some people they are the only option.
> 
> And they are not ever being removed from Perl, even as a far-future
> possibility. They are thus not discouraged by the definition of that
> term in perlpolicy. However contentious everything else may be, that
> much is unambiguously true.
> 
> 
> * Jerry D. Hedden via RT <perlbug-comment@perl.org> [2018-03-27 02:59]:
>> As one of several people who have maintained the various threads
>> modules over the years, I regret that I missed being part of the
>> original discussion that lead to the inclusion of the 'discouraged'
>> message.
> 
> Ditto.
> 
>> The fact is that threads work, they are maintained, and they currently
>> do not have any bugs preventing their use.
> 
> Ditto.
> 
>> I acknowledge that not all Perl modules are thread-safe, but there is
>> sufficient documentation to that affect in the POD.
> 
> Ditto.
> 
>> I also acknowledge that the threads implementation is not ideal nor
>> optimal. Nonetheless, threads are useful, and are being used in the
>> wild. (I, for one, have even used them to good effect in production
>> code. <Gasp!>) Yes, if you don't know what you're doing, threads can
>> be problematic. ("There be dragons...," and all that.) However, the
>> same can be argued to greater or lesser degrees of any programming
>> language feature in the hands of unsophisticated users.
> 
> Here we somewhat depart. To me the main point is that some people some
> of the time have no alternative to ithreads. And so if you need to use
> them, well then you need to use them.
> 
>> I feel that, while the wording of the POD notice is reasonable, the
>> WARNING heading is alarmist.  I feel strongly that the heading should
>> be changed to NOTICE, and the word 'discouraged' be changed to 'not
>> recommended' (as per the original poster's patch).
> 
> The discouragement notice just belongs deleted. I’m not sure that the
> heading would be too strong without it so I’m -0 on changing that.
> 
>> Since the addition of the 'discouraged' message, I have received
>> several emails from professional Perl developers from around the world
>> expressing concern about it.  I expressed to them the same opinions
>> I have given above, namely that threads work (but you have to know
>> what you're doing), and that threads have not been deprecated.
> 
> +1
> 
>> I'm not trying to convert anyone who doesn't like "interpreter-based
>> threads". Don't use them as you so choose. After all, Perl has always
>> been about options. However, there ARE Perl developers that do feel
>> they are a VERY useful feature.
> 
> This may depend on perspective. If I were in a situation without the
> choice of something else, I could imagine finding them VERY useful. :-)
> 
> 
> * Leon Timmermans <fawaka@gmail.com> [2018-03-28 02:30]:
>> I think the main problem with the current wording is that it
>> discourages without explaining why.
> 
> There is a long list of appropriately neutral explanation of footguns,
> but only miles down the page under BUGS AND LIMITATIONS. There has to
> be a reference to that.
> 
>> In particular it doesn't explain that threads.pm does something
>> different than what many people expect it to do.
>>
>> People expect it to be good for "share all the data" scenarios
>> (because pretty much anything else called threads is), even though it
>> is terrible at that. This confusion isn't helped by threads
>> implementations in commonly used implementations of languages
>> occupying the same niches as we do (e.g. cpython, Ruby MRI) sucking in
>> exactly the opposite way (they're good at sharing but useless at
>> actually being parallel).
>>
>> It's not so much threads.pm that needs a big fat warnings, it's
>> threads::shared that does.
> 
> +1
> 
> I would be in favour of a second patch which adds this up top, which can
> be bikeshedded if people feel strongly enough about it. I am willing to
> propose new language for that.
> 
> First up I’d want to remove the untrue statement, however.
> 
> 
> * Rocco Caputo <rcaputo@pobox.com> [2018-03-27 16:35]:
>> I started the discussion that led to the addition of the
>> discouragement warning. Its original purpose was to manage users'
>> expectations of the kind of help they'd get from the larger Perl
>> community for trying to use this feature. […] Getting rid of the
>> notice entirely would resume failing to manage users' expectations.
> 
> The notice was simply incorrect and therefore could not possibly manage
> users’ expectations correctly. If the fact that you’re talking about is
> that using threads will get you yelled at by some, then how is any user
> expectation managed correctly by *not* telling the user that and instead
> just telling them to not use threads?
> 
>> In case someone on-list isn't aware of the advice given off-list, I'm
>> closing with a small list of quotes from freenode #perl. These are
>> pieces of real advice given to Perl users looking for help using
>> threads. Some of you may recognize things you've said.
> 
> How heavy is the tail on the long tail graph of who these quotes came
> from? How many counterexamples of users getting real help with threads
> are there?
> 
>> Some of you may be tempted to say that IRC isn't representative of
>> a larger perl community, but many of the vocal opponents on IRC also
>> participate in other areas. They use and advocate Perl professionally.
>> They attend or speak at Perl conferences. They are perl5 porters.
> 
> Are you aware that what comes after your “but” doesn’t rebut what comes
> before it? :-)
> 
> 
> * Sergey Aleynikov via RT <perlbug-followup@perl.org> [2018-03-26 01:29]:
>> On Sat, 24 Mar 2018 09:31:06 -0700, choroba@matfyz.cz wrote:
>>>       From time to time, we may mark language constructs and
>>>       features which we consider to have been mistakes as
>>>       discouraged.
>>
>> Threads in their current implementation are arguable a mistake. You
>> loose ~30% of performance and who-measured-how-much memory by just
>> using perl build with threads. And most of XS CPAN is up to some
>> degree threads-unsafe (pure-perl CPAN is safe, so the goals for
>> threads is reached, but still).
> 
> Any feasible implementation would be a mistake of a different kind. So
> faced with the problem of needing some kind of threads but having only
> bad choices for their implementation, Perl made a different bad choice
> than other similar languages. (Cf. Leon’s reply.)
> 
> And no random scary numbers pulled out of a hat please. I don’t mind
> mentioning that thread-supporting perls are slower at an above-noise
> level, but if you’re going to quote specific numbers, they must come
> with actual benchmarks to contextualise them. Just “30% slower!!1!” is
> FUD. (I myself compile my perls without threads, because if I never ever
> use threads then why pay for them? That is an argument that holds even
> in absence of any exact figures.)
> 
>>>      Discouraged features aren't currently candidates
>>>       for removal, but we may later deprecate them if they're found
>>>       to stand in the way of a significant improvement to the Perl
>>>       core.
>>
>> Threads are not going anywhere by this definition.
> 
> Indeed.
> 
>> Just discouraged.
> 
> In the colloquial sense maybe, but as you found, not in the perlpolicy
> sense.
> 
> 
> * Sergey Aleynikov via RT <perlbug-followup@perl.org> [2018-03-28 03:04]:
>> On Mon, 26 Mar 2018 18:21:02 -0700, public@khwilliamson.com wrote:
>>> I agree with the above. And I really don't like 'not recommended' as
>>> I think it is too strong. Maybe just list the problems
>>>
>>> Even a 30% slowdown will be fully acceptable if you can divide the
>>> work up into 8 or 16 parallel pieces. The gain far outweighs the
>>> cost.
>>
>> But if you use processes for parallelism and not threads, you don't
>> get this slowdown at all and get the same multicore boost. And you
>> don't have to guess which XS module will segfault next.  The only case
>> when I find using threads reasonable is writing GUI, where you _have
>> to_ be in the same address space.
> 
> Except some people do not have the option.
> 
> 
> Regards,
> 

It turns out that #125106 also is about this topic, and I have merged 
the two tickets.  You might want to look at the discussion there.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About