BrowserUk

There's a distinction to be made between "discouraged" and "deprecated" with respect to the status of threading. I followed the discussions on the p5p mailing list out of curiosity. It appears that a few people grew tired of answering questions about threads (I think in IRC), and felt that threads' correct use was sufficiently complicated that it would be in everyone's best interest if newcomers were discouraged from using them. But it's my understanding that there's no intention of removing them entirely.

Here are a couple of related messages from P5P. The entire thread may be worth reading (at least I found it interesting).

• http://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html
• http://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213457.html

I disagree with the strategy of "This is hard to use correctly so let's tell people not to use it." I think it's an over-reaction. If something is too difficult for some people to use correctly, that doesn't mean that it's of no value to those who have taken the time to learn how to use it properly. Most of the rest of Perl's documentation does a reasonable job of mentioning, "...this feature is deeply magic. Here be dragons." ...That sort of thing. There's nothing wrong with just documenting the complexities and suggesting that for many situations forking is easier to manage, rather than to strongly discourage the use.

A "Best Practice" might be to favor one approach over another in a general sense. But we all know that threads have specific uses that are not easily replaced with other technologies. For that reason, I think that "discouraged" is probably too strong.

But I do think to be fair one should recognize that they are not deprecated, and nobody is talking about removing threads from Perl.

I'd say this issue ("it's hard to use threads correctly") has at least four separate aspects worth considering in the context of Perl 5 and its documentation:
1. Is concurrency appropriate? There are two basic motivations that can lead to use of concurrency constructs in programming: 1) because the domain naturally involves asynchronicity and 2) to speed things up. In the latter case, if the problem being tackled is really IO bound, turning to concurrency probably won't help.

   It might be worth providing some simple rubrics in some Perl documentation to help folk figure out when concurrency likely will or won't be helpful.

2. The Problem with Threads. For all but trivial problems, correctly using conventional low level concurrency constructs such as threads and locks is surprisingly difficult. This is true for all langs, even, say, erlang or clojure. It has nothing whatsoever to do with Perl.

   It might be appropriate to warn most programmers away from use of low level constructs. Perhaps "Here Be Dragons And They WILL Burn You" goes too far and a link to "The Problem with Threads" or somesuch will suffice.

3. Futures et al are the future. There are much simpler, safer, higher level ways to do concurrency. I haven't tried Paul Evans' Futures, but they look the part.

   It think it is appropriate to encourage most programmers to use these higher level constructs.

4. Perl 5 "threads" are very heavy. This sometimes introduces additional complexity.

   I'd say this is worth mentioning, but it's perhaps the least important of the four points (though perhaps the most annoying to those expected to answer questions about them).

Finally, I'll note that the section Make the hard things possible in the P6 synopsis on Concurrency says:

Perl 6 should not hide the existence of OS-level threads, or fail to provide access to lower level concurrency control constructs. However, they should be clearly documented as not the way to solve the majority of problems.

»ö« ^{. o O ( "the celebrity tell-all of the Perl-6 cult?" )}

Pugs is abandoned. Cross that off your list.

Use Rakudo. Rakudo supports a number of different VMs. Its support for Parrot is the most mature, but if you want threads forget that. Threading is still a "coming soon" topic for Rakudo on MoarVM and JVM. If I had to place a bet on one of them, I'd go with JVM, as the JVM itself already has tried and tested support for threads.

»»» This post is about the immature Perl 6, not the rock solid Perl 5 «««

Why do you say threading support is "coming soon"? The implementation is immature and there's lots more to spec and implement over coming years but pretty much all the classes, methods, etc. named in the Concurrency Synopsis are implemented in Rakudo and that's a pretty substantial set of tools, sufficient for many scenarios.

There's no regular end user doc. There's the Concurrency Synopsis and jnthn's Reactive programming in Perl 6 presentation (make sure to use the latest version of the example code in the reactive examples code repo; and here's a video if you like watching "Bob"). And/or checkout Perl 6: what can you do today? which is built around an extended example, including applying concurrency toward the end.

The JVM and its JIT are mature, making it the right choice for a lot of concurrent or long running code. MoarVM is immature but uses a lot less RAM than JVM, starts much faster, is where most optimization work is being done, is where key features such as NFG (for Unicode data) are due to be implemented first, and is most devs' preferred backend.

I'd advise waiting for the next Rakudo Star, due in a few weeks from this list, and trying code with both MoarVM and JVM backends.

(8.25 updates: JVM is mature, there was no 2014.07 Rakudo Star. Thanks to whoever added the 8.25 update. A 2014.08 Rakudo Star is now available. I also edited the bit about maturity to make it clearer that MoarVM is immature.)

»ö« ^{. o O ( "the celebrity tell-all of the Perl-6 cult?" )}

Perhaps threading is better implemented than I thought. My knowledge may well be out of date in this area. Though I'll note that even moarvm.com says:

"For long-running workloads where startup time doesn't matter, or when you need tried-and-tested, mature threading support, Rakudo on the JVM is a better bet; its JIT compiler gets to work and makes quite a difference."

Certainly I'd agree that overall MoarVM is likely to turn out to be the best Perl 6 VM. But the question asked specifically about threading, and it looks to me like the JVM backend is the best bet - at least for now.

toby döt ink

There's no regular end user doc. There's {the Concurrency Synopsis} and jnthn's {Reactive programming in Perl 6} presentation

A year on and there remains one problem with both those links: it not that they are fantasy -- they are, but that's not the problem -- its that the people around the authors of those documents don't realise that that are fantasy.

+=head1 WARNING
+
+The "interpreter-based threads" provided by Perl are not the fast, li
+ghtweight
+system for multitasking that one might expect or hope for.  Threads a
+re
+implemented in a way that make them easy to misuse.  Few people know 
+how to
+use them correctly or will be able to provide help.
+
+The use of interpreter-based threads in perl is officially
+L<discouraged|perlpolicy/discouraged>.
+
[download]

Which is just FUD, recipes instead of warnings