"Blocking Buffered Stream" threading primitive

Nicholas Clark nick at ccl4.org
Mon Dec 26 12:56:48 UTC 2011


On Sun, Dec 25, 2011 at 03:31:36PM -0500, Daniel Ruoso wrote:
> Hi All,
> 
> I have been thinking about Perl 6 concurency model for a while now,
> and I think the hybrid threading model is on target to what a HLL will
> need, but I think we need one more primitive.
> 
> The point I'm trying to address is the one that in Perl 6 we are going
> to have a lot of implicit threading constructs, such as:
> 
> my @a <== grep { foo() } <== map { bar() } <== 1..inf;
> 
> In this simple construct, the main program will actually continue
> immediately, while a set of new "Task"s are going to be created for:
> 
> 1: produce the range 1..inf
> 2: do the first map calling "bar()"
> 3: do the grep calling "foo()"
> 
> The spec for Perl 6 is still a DRAFT around this topic, but it is
> mostly accepted that the interpreter is free to start processing some
> of this immediately, and is not required to strictily wait until some
> value is actually used.

Does Perl 6 mandate a threading model akin to POSIX, were the threads of
execution all run with shared state, something more like Perl 5 ithreads
(or I guess a message passing system) where everything is decoupled, or
"it doesn't mandate anything"?

> What do you think?

> daniel
> 
> P.S.: I am not subscribed to the parrot-dev list, please CC-me.

Presumably the Perl 6 compiler is only allowed to implicitly parallelise the
above construction if it can be sure that foo() and bar() have no side
effects?

Presumably this sort of threading only pays off if the CPU gains from
using multiple cores more than offset the cost of creating the threads, and
passing return results back?

Nicholas Clark


More information about the parrot-dev mailing list