On Fri, Oct 15, 2010 at 10:56 AM, Tim Bunce <tim.bu...@pobox.com> wrote:
> Another important issue here is portability of concepts across
> implementations of perl6. I'd guess that starting a thread with a fresh
> interpreter is likely to be supportable across more implementations than
> starting a thread with cloned interpreter.
> "Well volunteered!" ;)
Hi, I don't have much to offer on the topic of concurrency, but as
someone who is in the process of slowly implementing a native-ish code
compiler for Perl 6 (technically probably a compiler to LLVM assembly
with the intention of then compiling to native code), I'd like to
remind everyone that not every implementation will have an
interpreter. I don't think you actually necessarily mean an
interpreter here, but rather whatever structure is analogous to that
which, in an interpreter, would hold the interpreter's "global" state.
If this is the case, I think it may be helpful to state more precisely
what state you think would need to be cloned or recreated between
"threads" or "processes" and what would not.
Also, it is important to consider how different designs will affect
the complexity and performance of concurrency primitives for Perl 6
implementations (especially for more common implementation
strategies), but neither "interpreter" nor "VM" appears in a quick
grepping of S17. I don't think that should change.