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

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

Thread Previous | Thread Next
Tom Molesworth via perl5-porters
April 10, 2018 12:41
Re: [perl #133021] Removed the word "discouraged" from threads'documentation
Message ID:
On 10 April 2018 at 05:01, Christian Walde <>

> On Mon, 09 Apr 2018 12:37:54 +0200, Dave Mitchell <> wrote:
> Is this based on the idea that the ithreads implementation itself is
>> inherently buggy, or that some modules may not be thread-safe.
> My current assumption is the latter. However i cannot speculate at all as
> to whether it might be some of column A or not.

The official documentation claims that the current code has what
I'd class as "bugs":

        Even with the latest version of Perl, it is known that certain
        constructs with threads may result in warning messages concerning
        leaked scalars or unreferenced scalars. However, such warnings are
        harmless, and may safely be ignored.

If they are leaking, this has bad implications for long-running code.
If they're not leaking, why the warning?
If this information is out of date, then the bugs are in the documentation!

> 2) If one's threaded code randomly craps out due to a 3rd party module
>> being non-thread-safe, or supposedly thread-safe but buggy, then that's an
>> issue with the third-party module. In principle any programming language
>> will struggle with threads if used with a 3rd-party library that isn't
>> thread-safe.
> This has dangerous assumptions in it:
> - Thread safety is not a binary on/off switch. Modules can appear to be
> thread-safe under some conditions and not be so under others. That's why i
> called it a heisenbug in my previous email.

Indeed, this is arguably worse than clear "the code crashed so it doesn't
work" cases.

We also don't have good documentation on how to make modules thread-safe:
I've encountered quite a few Perl developers who are confident that thread
safety is only an issue with XS.

As an example: far as I recall, the documention and perlmod page
to which they link never explicitly state that ref addresses will be
different in each thread:

    perl -e'use threads; use Scalar::Util qw(refaddr); my %x; $x{refaddr
$_} = $_ for [qw(x)], [qw(y)]; threads->create(sub { warn threads->tid . "
=> " . join ", ", map { "$_ (" . refaddr($x{$_}) . ")" } sort keys %x
})->join for 1..2'
    1 => 30822192 (32355200), 30948440 (32355272) at -e line 1.
    2 => 30822192 (32355456), 30948440 (32355528) at -e line 1.

I know much of my CPAN code will be susceptible to this type of issue. Any
time someone asks about thread safety, I point to the "discouraged" line in
the official documentation and explain that I don't expect my code to work
when multiple threads are active - "maybe try again if we have a new
threads implementation in the future".

Downgrading that warning to something less clear could have unfortunate
consequences for people learning (or supporting those who learn) Perl. I'm
also not entirely convinced that "discouraged" is the wrong word - taking
the phrases from the official policy:

From time to time, we may mark language constructs and features which we
> consider to have been mistakes as discouraged.

- Windows support: not a mistake. Exposing the API to end users without
warnings and clear information about how threads differs from other
languages, on the other hand - maybe not ideal.

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.

- surely this is the case? If we come up with a better way to implement
threads while retaining the ability for Windows to support some form of
process emulation and related features, wouldn't this be something that's
welcomed? I don't get the impression that there's widespread satisfaction
with the current state of affairs on either or threads::shared.

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