Thank you for taking my concerns seriously. As you can see, many do not.

When I first read the PPD (18 months or so ago?), and when I was taking part in the background discussion from which it is in large part derived, 3 or 4 years ago, I too allowed myself unbridled optimism.

Here, today, it is still not possible to start a second interpreter in parrot. And none of the code that has so far been written has been ever been tested for reentrancy. There is no visible segregation between memory that represents code and data at the VM level. There is no segrgation between local constructs and global constructs.

Say, as the PPD does, that you are going to 'do everything', but make no provision to ensure the constraints that everything imposes upon the rest of the design, means that all of those constraints will be violated all over the code base and will only be discovered once you come to try and implement the vision.

At that point, you are basically looking at re-writing everything; or the most likely scenario, deferring 'everything' "for now", with the promise of retrofitting it over future releases. Retro fitting threads into a mature architecture is exactly the problem, with exactly the effects that perl 5 iThreads has suffered.

But, as the latest anonymonk denial shows, there continue to be a large percentage of persons that believe that my concerns for threading are simply because I'm 'stuck' on a broken platform; that thread is spelt F - O - R - K; that event driven architectures are a substitute for threading; and whilst that remains the case, there is little hope for effective threading on Parrot, and by extensions, those languages that run on top of it.

But, now I am just hand-wringing, so I'll crawl back in my shell and shut up. Again.