On Fri, Aug 19, 2011 at 7:38 AM, Patrick R. Michaud <pmich...@pobox.com> wrote: > 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.
Hyperoperators are the example we've heard about most often, but are also a particular case. Hyperoperators, from my understanding of them, would seem to benefit more from light-weight green threads (greenlets, stackless threads, whatever you want to call them) than heavier-weight OS-level threads. Actually, I think they would benefit well using a hybrid approach, you do need multiple channels to dispatch the greenlets to. If we had an API available in Parrot that would use continuations to simulate green threads, with the promise that eventually they would be backed by an OS-thread dispatcher, I think that would be a good first step. We would get to start playing around with the primitives and APIs necessary, and be able to implement the details later. > 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.) As a tangential note, migrating 6model into Parrot and integrating it into the VM fully could potentially be as much work or more than implementing it in NQP as originally. It's not the same kind of effort, and it might not all have been avoided had 6model been developed directly in the Parrot repo, but it is something to think about. Like with 6model, if NQP/Rakudo come up with a compelling system while we're still unable to finalize a design for ourselves, it's very likely that we would try to *borrow* it in Parrot core directly. What's standing in our way right now is the need to support multiple different languages. We want to provide something, but if we provide too much it's going to create problems with different HLLs, etc. If Rakudo can prototype some of the bare-minimum primitives they need, it might become a good platform for us to build up from. --Andrew Whitworth
