Front page | perl.perl5.porters |
Postings from April 2018
Re: [perl #125106] Why are threads discouraged?
Thread Previous
|
Thread Next
From:
Karl Williamson
Date:
April 10, 2018 15:09
Subject:
Re: [perl #125106] Why are threads discouraged?
Message ID:
be1d25be-c08c-1e10-315d-910c45ec2ef4@khwilliamson.com
On 04/10/2018 07:42 AM, Sergey Aleynikov via RT wrote:
> On Tue, 10 Apr 2018 04:04:06 -0700, davem wrote:
>
> The problem is in people's expectations. When most part of something is thread-safe, they'll just assume "everything is thread-safe" and then'll be hit very hard. One of the examples I like is Mouse, which was thread-unsafe until the year 2015. While it's not as popular as Moose, it's still a module with large a large user base. And your chances to encounter bugs in not so popular XS modules are much, much higher. What's even worse, you're likely to hit them only under some unlucky circumstances (see example below).
>
> As for the core, I agree that it's now much more thread-stable than before. Somewhere around 5.12 or 5.14 I've prepared a talk named "no threads" with some nice crash examples in it - they crash no more. But still, locale handling was thread-unsafe until 5.24 (or 5.26?) - just because of no one has discovered that.
Actually threaded pure perl programs are still unsafe in 5.26. perl
switches the locale behind your back, even if you follow our admonitions
to not explicitly use locales. I'm to blame for some of these, in my
earlier naivete, and some have been there for a long time. Sergey found
one case that I added in 5.24 I believe, and contributed a test file to
verify it's still fixed
5.28 uses thread safe locales if available on the system. On other
systems, I avoid switching locales, and added a mutex for those cases
where switching is still done.
When perl starts up, it reads the environment to see what each locale
category should be set to. If not all categories are set to the same
thing, this would cause perl to potentially switch locales to gather
information about the outliers. This is potentially problematic on
unsafe threaded builds. I solved this by gathering the information at
start up, and caching it. This is one of the ways 5.28 avoids switching
locales.
In researching this, I looked in the POSIX standard for functions it
allows to be non-thread safe. I have a WIP to add cautions about these
to XS writers. I also noticed that the Linux man pages indicated that
they have failed to implement correctly some that are supposed to be
thread-safe. Other systems may implement these safely, but not others.
I searched the perl source code for instances of these calls. And then
manually started to examine them to see if there was a problem. I have
not finished (and of course I may make mistakes in my analysis). The
glaring case where there is a problem is in accessing the environment
(getenv() et.al.) These need to be protected by a mutex, but it's only
a problem if another thread is changing the environment at the same
time, a much less common occurrence. My guess is that these aren't
crashing things because most environment changes would tend to be done
at start-up, even before thread creation. Things you might not expect
to, without thinking about it, like tzset(), do access the environment,
and there is a potential race if the environment is changed by another
thread during tzset's execution. And tzset is called from places that
at first glance you wouldn't expect.
And the following still fails loudly (though nott dumps a core);
>
> while (1) {
> push @foo, threads->create(sub {
> require IO::Handle;
> });
> $_->detach for(splice @foo);
> }
>
> So while yes, perl is much more thread-safe inherently as it used to be, I won't recommend using threads in it to anyone.
>
> ---
> via perlbug: queue: perl5 status: open
> https://rt.perl.org/Ticket/Display.html?id=125106
>
Thread Previous
|
Thread Next