A person can talk and talk and then complain about how no one jumps to write code for said person,

Show me one example where I have asked anyone to write code for me?

Show me where I've ever complained that no one has written code for me?

That really depends on what you mean by "tack-it-on-later". The concurrency PDD is still unfinished, and, as such, not completely implemented.

At it's basic level, starting a second interpreter in a second thread should be simple. If you can then run any of your tests in two interpreters concurrently on a multi-cpu machine, you can be pretty certain that your infrastructure is re-entrant and therefore a good basis for whatever threading model is chosen to abstract that.

Forget cloning. Forget locking. Forget sharing. (For now!) Just the same piece of code (CV* in p5 terms), running concurrently on different data.

And that test (those tests) should be re-run as a part of the FV test suite as Parrot evolves, because anything that causes that simple test to break is going to become a show stopper, or at the very least, a huge re-work at later stages.

If that test is not in place, unless the Parrot developers have multi-threaded brains with which to envision the code paths and effects of the code they are developing, then they are building a system onto which threads will have to be tacked on later, and are likely to end up with exactly the same scenario as we have with p5 threading.

Here's your chance to suggest a better threading model than ithreads or pthreads.

I stuck my head in that lion's cage a long time ago. And much of the vegetarian message I attempted to delivered then remains true today. Through my acquiring a greater understanding of the specific limitations of using (and cursorily, implementing) threads in interpreted languages, by attempting to use them, in Perl 5 and other languages, I've seen other limitations and non-solutions (like the whole 'holy COW magic bullet' non-solution), that have modified my take on things, but mostly, couched in non-POSIX terms as it was, remains as true and unpalatable today as it ever was.

As far as I am concerned, ithreads is a perfectly fine threading model. That is, explicit-only sharing. Its p5 implementation leaves a lot to be desired, but the model is fine. The main problems with the p5 implementation are exactly those places where the expicit-only rule is broken. As in the cloning of stuff anything that already exists. Ie. the attempt to emulate the forking paradigm.

The main point: Shared data is global data.

Shared lexicals (in terms of existance rather than scope) don't make sense. By segregating shared data from local (lexical) data, the lexical data can be entirely deviod of any need for locking--user or internal. That means that code that does not use threads or shared data, carries none of the overhead of internal locking.

If Parrot generated code is reentrant, then it can run on any interpreter. If shared data is global it can be accessed by any interpreter. That is, the actual data, not some proxy of as with the p5 imlementation.

If only global data can be shared, then lexical data can only be accessed from the thread in which it was created, so no locking is ever required.

P5 has these two distinct sets of data already. Globs and (what I think are called) stashes. In the p5 implementation, both can be shared, so both have to carry the overhead of internal locking. That's what makes threaded builds so much slower than non-threaded builds.

If parrot had a similar split between global and local data, and only the globals could ever be shared, then only opcodes that deal with globals would need to carry the burden on internal locking and serialisation. Non-threaded code that didn't use globals could run at full speed even on threaded builds.

There's more, but if those two things--shared == global and all generated code is reentrant--were in place and ensured, then everything else can be decided upon and coded later.

I've brought most of this up here at one time or another, but I appreciate that it isn't particularly convenient for you to search around looking for it. But then, it's not particularly convenient for me to consider gathering it all together knowing full well that it's going to be ignored because I don't write unix code.