FWIW, here are a few of my thoughts on these items.
On Wed, Aug 17, 2011 at 04:01:23AM -0700, Christoph Otto wrote:
> 1) Threading - this isn't a pressing concern right now, but we'll need
> to something about it in the near future. nine, (a.k.a. Stefan
> Seifert) dropped by #parrot and is apparently here at yapc. I'll try
> to find him. [...]
FWIW, I think a useful place to start playing with threading in
Rakudo would be the hyperoperators. In src/core/metaops.pm there's
a multi sub hyper(\$op, \$obj) that performs an operation ($op) on
all of the elements of the list in $obj. This ought to be a very
good candidate for parallelization. Here's an example that will use
this hyper candidate:
my @a = 1..5; @a>>.say;
This will produce something like "2\n1\n5\n3\n4\n" -- i.e,. the result
of invoking .say on each element of @a. Note that hyper operations are
allowed to run in parallel so that the order isn't guaranteed (Rakudo
currently simulates this by shuffling the order of operation, so that
programmers don't come to rely on an inorder interpretation.)
Anyway, being able to convert the hyper() function to use threading,
would be really awesome, even just as a proof of concept.
> 2) Asynchronous I/O - This also isn't urgent, but will become
> increasingly important. People have come to Rakudo and said that
> they'd start hacking on web apps once A I/O was implemented. We need
> to figure out what primitives we need to provide to HLLs, then
> provide them.
For the last several months I've been advocating that Rakudo simply
implement (and explore) async I/O in the Rakudo repository for a while,
so that Rakudo can figure out what primitives we'd like to have. Then
when we've identified those primitives, we can look at how to provide
them in Parrot.
The basic idea is that it's simpler to do rapid experimentation and
exploration within just one repository (i.e., Rakudo) than to try to
coordinate between two of them. When things are stabilized, then
we can see if it makes sense to move an implementation into Parrot
for use by other HLLs. (This is similar to the approach we've taken
with 6model.)
Pm
