"Blocking Buffered Stream" threading primitive

Daniel Ruoso daniel at ruoso.com
Sun Dec 25 20:31:36 UTC 2011


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.

So, the way I think we could make this work would be to have a
"blocking buffered stream" primitive, so that thread 1 would start
producing and feeding to the first stream, which would be consumed by
the second task, processed by map and fed into the second stream,
which would be consumed by the third task and processed by grep and
fed into the third stream. The third stream would only be consumed as
values were read from @a. Since the code would not immediately consume
data from @a, the third stream would quickly have its buffer filled
up, so task three would block, thus stop reading the second stream,
causing the second task to block, thus stop reading the first stream
which would finally block the first task.

Basically this is the equivalent of a unix pipe and would provide
primitives for making tasks block/unblock based on how data is
produced/consumed on each side of the stream. I think it needs to be
low-level to change the status of the task in the most efficient way
possible. I am not sure it would be possible to do it in any efficient
way from a higher level.

What do you think?

daniel

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


More information about the parrot-dev mailing list