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!" ;) > > Tim. >
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. -- Tyler Curtis
