On 10/05/11 08:46, Peter Lobsinger wrote: > My take is that this shows that a thread-safe interpreter which leaves > user-visible parallelism to external libraries is a viable concept. > Parrot should make solutions like threads::tbb possible in stead of > focusing on providing a hardcoded core concurrency paradigm.
Right, but at some level you have to provide a set of primitives which complement the API of the virtual machine. With Perl 5, the primitives are the Perl 5 C API (ie perlguts) and the cloning and embedding APIs. A nicer set of primitives to allow might be that used by Erlang, Go, TBB, etc: starting with lightweight threads / tasks, then adding data synchronisation primitives (channels/queues in Erlang and Go, or a choice of queues, arrays or hash maps in TBB). You can build all the various types of parallelism approaches on top of those. If you look at the C++ templates for TBB, they all derive the 'task' class under the hood. The bit which is hard to retrofit is knowing what is "const" or otherwise conformant to the required thread safety API. You either assume const by default for safety (as in Erlang), keep track of it on structures (which partially happens in C++), or just give up and make it the user's problem (as in Java and my Perl module). The reason for this is so that pointers (or whatever handles are issued for live objects) can be passed around safely without having to clone everything everywhere. Sam _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
