Front page | perl.perl5.porters |
Postings from April 2018
Re: [perl #133021] Removed the word "discouraged" from threads'documentation
From: Sawyer X
April 5, 2018 08:40
Re: [perl #133021] Removed the word "discouraged" from threads'documentation
Message ID: firstname.lastname@example.org
I agree with pretty much every point Aristotle made here. I want to
highlight some issues to move forward on:
* As Aristotle explains, this definition of "discouraged" does not match
what it means in perlpolicy. It might meet what we refer to in
day-to-day communication, but this creates a gap between that and what
our policy states it is. This is important because our technical
decisions must conform to the policy. We must then remove the
* There is still room on how to define this recommendation to avoid. I'm
personally fond of the short-but-honest get-to-the-core descriptions,
such as "This might not be what you want" or "This will likely not work
the way you expect it to" or "This isn't what you would this it is" or
"Unless you know how this works, you will want to stay clear of it."
There are far better English speakers who could provide a nuanced
phrasing and far better explanation of why this isn't what you wish,
* I think we definitely need to add more explanations (both on threads
and threads::shared) for the difference in behavior vs. expected
behavior, allowing users to jump from short-and-sweet to the details,
helping them make a decision of whether they want to use threads.pm or
not - and if so, how.
* As Aristotle requested: We should not put numbers without benchmarks.
We can say "noticeably slower" or "noticeably slower for <usages>." This
is honest and far more useful, IMHO.
* It would also be good to do the counter of suggesting not to use
threads (or pointing at the grain of salt you have to take when wanting
to use it), which is to note when it *is* useful to use threads,
providing the narrow cases in which it shines or works the way you
expect it to (or the way it's designed to).
Did I miss anything?
On 03/29/2018 11:46 PM, Aristotle Pagaltzis wrote:
> * E. Choroba <email@example.com> [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 <firstname.lastname@example.org> [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
> 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 <email@example.com> [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'
>> The fact is that threads work, they are maintained, and they currently
>> do not have any bugs preventing their use.
>> I acknowledge that not all Perl modules are thread-safe, but there is
>> sufficient documentation to that affect in the POD.
>> 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.
>> 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 <firstname.lastname@example.org> [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.
> 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 <email@example.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 <firstname.lastname@example.org> [2018-03-26 01:29]:
>> On Sat, 24 Mar 2018 09:31:06 -0700, email@example.com wrote:
>>> From time to time, we may mark language constructs and
>>> features which we consider to have been mistakes as
>> 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
>> Threads are not going anywhere by this definition.
>> Just discouraged.
> In the colloquial sense maybe, but as you found, not in the perlpolicy
> * Sergey Aleynikov via RT <firstname.lastname@example.org> [2018-03-28 03:04]:
>> On Mon, 26 Mar 2018 18:21:02 -0700, email@example.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
>> 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.