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

Re: [perl #125106] Why are threads discouraged?

Thread Previous | Thread Next
Karl Williamson
April 10, 2018 15:09
Re: [perl #125106] Why are threads discouraged?
Message ID:
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 

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()  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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About