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

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

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
April 10, 2018 14:28
Subject:
Re: [perl #133021] Removed the word "discouraged" from threads'documentation
Message ID:
20180410142745.GC25122@iabyn.com
On Tue, Apr 10, 2018 at 08:40:45PM +0800, Tom Molesworth via perl5-porters wrote:
> The official threads.pm 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!

That text is 11 years old and should be removed.

> > 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.

Any threaded program in any programming language is susceptible to subtle
heisenbugs. I'd argue that perl is less susceptible than many languages
due to its 'not shared be default' nature.

> 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.

I'd be one of those, in the sense that the perl language itself is
thread-safe, and doesn't normally need locks or special handling; but in
any environment where there are multiple concurrently running threads,
there will be some extra considerations required.

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

Since the whole basic principle of ithreads is that data isn't shared by
default, it would be astonishing if two (non-shared) refs in two different
threads had the same address.

> I know much of my CPAN code will be susceptible to this type of issue.

Do you think there are many such issues, or is ref addresses the main one?

> 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".

Fine - add to the pod in your modules that they're not thread-safe.

> - Windows support: not a mistake.

Yet I suspect many complaints about bad threading behaviour in perl (such
as ref addresses changing in a sub-thread) applies just as much to the
Windows fork emulation - e.g. do a pseudo-fork on Windows and all the
ref addresses change. I don't see you we can praise one and condemn the
other.

> 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.

I am all in favour of having, at the same location as the current
'discouraged' text, but instead of it, a big flashing neon sign saying
that perl threads are a bit different from what you might expect and only
use them if you understand that (e.g. each thread is a non-shared clone
of the parent, with memory and start-up-cost implications).

> 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 threads.pm or threads::shared.

Even if we ended up doing Windows fork() differently, I wouldn't (at the
moment) advocate deprecating or removing threads.pm threads::shared, or
the underlying core implementation.

-- 
"I do not resent criticism, even when, for the sake of emphasis,
it parts for the time with reality".
    -- Winston Churchill, House of Commons, 22nd Jan 1941.

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