Parrot threads as default

[Reini Urban]

On Mon, Dec 17, 2012 at 7:06 PM, James E Keenan <jkeen at verizon.net> wrote:
> Am I correct in thinking that Parrot now builds with threads by default?

Yes.

> I.e., that if you *don't* want to build with threads you have to explicitly
> opt-out by saying:
>
>   perl Configure.pl --without-threads

No, that is not possible yet. threads support is builtin.
--without-threads will cause HAS_THREADS to be set to 0, but we
haven't tested this configuration.

> I ask as a relatively threads-ignorant person (which I think most software
> developers probably are).  For example, I have never built a threaded Perl
> 5, nor, to the best of my knowledge, have I ever run on one.  And during the
> many months in which the threads branch was under development, I was mainly
> concerned with one question:  Which tests were breaking?

Unfortunately it is not easy to come up with breakage tests.
Similar to the breaking readline IO tests, which expect user-input.

> So, I would welcome a presentation -- and perhaps inclusion in our
> documentation -- of issues such as:
>
> * Why does Parrot now build with threads by default?

Because this is IMHO the single most important feature since 15 years
of perl development.
This is the feature which seperates perl6 from perl5. Which would get
perl6 some momentum over perl5.
The hyper operators parallelize lists automatically to saturate all
available CPU cores.
  hyper - forces none-lazy list context, that ignores the order of
results (allows parallel computing)
Manual safe and fast background processing.

> * What exactly does "building Parrot with threads" mean?

That parrot supports threads now.
Green threads as described in pdd25_concurrency, plus native OS thread support.
See also http://perl6advent.wordpress.com/2012/12/11/day-11-parrot-threads/ for
a short overview and the links in the docs for more.

> * Under what circumstances would you want to build '--without-threads'?

If you want to forbid the experimental minefield, which threads with
GC can cause.
However, I would not recommend --without threads.
--without-threads does not set HAS_THREADS.
However HAS_THREADS has been set for the last year, even without
threads support.
So nqp and rakudo can not rely on HAS_THREADS for previous parrot
versions. (They can now).
The best feature I came up with was #ifdef PARROT_THREAD_H_GUARD
We did never tested  --without threads.

Tasks work even --without-threads, pthreads are enabled even --without-threads

I would recommend testing and enabling threads support in your application
(nqp and perl6 being the most important),
while we get the remaining GC problems with threads under stress fixed.

parrot is stable if you don't invoke Task subs.
It is experimental if you invoke Tasks.

All parrot tests pass, most examples pass correctly, but there are
some platforms which might fail in the GC with threaded functions. If
you stress the GC in threaded functions you might get segfaults, esp.
on darwin.
It was not possible to break threads on windows though, and it is much
harder on linux.

A short summary of this will be in the release announcement of course.
I could not fix the GC bugs alone, we need some efforts to get it done.
I pushed some of my efforts to rurban/fix-gc-thr-gh880+gh875
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/