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

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

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
March 29, 2018 20:47
Subject:
Re: [perl #133021] Removed the word "discouraged" from threads'documentation
Message ID:
20180329204617.GA19453@plasmasturm.org
* 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,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

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