Things have moved on. The ppds in my (dormant) Parrot/docs/ppds directory run from 00 through 18.

It's good to hear that threading is being actively thought about. As I've expressed elsewhere, I fear that any implementation of threads that work well, will have considerable impact upon existing code that was not written with threading in mind. Or it will be a 'tack on' solution.

I also fear that using the POSIX pthreads api as the basis for the design of the threading support will severely limit the functionality of threading on all platforms that have a richer set of primitives and/or higher level encapsulations. This includes not only Win32, but also many flavours of *nix, which have non-POSIX extensions to the basic pthreads apis. And many different, incompatible extensions to boot.

I think that a richer, virtualised API--not specific to any single existing platform's set--is required to allow access to the full range of threading API's on all platforms. Actually, I think a VM should virtualise all OS interactions, including and especially memory management. And that this should be done way down low in the architecture, so that the vast majority of the VM's infrastructural code has no direct access to the OS or (C) runtime libraries whatsoever. I see that as being the only way that it could ever hope to make full use of the strengths and variations in native OS/runtime facilities on all target platforms.

And that does not mean simply hiding the basic POSIX apis behind sets of macros as is mostly the cae with Perl5. Whilst I agree that POSIX is the nearest thing to a cross-platform OS specification available, it is sadly out of date even on modern *nix platforms. As such it is a 'least common denominator solution. On non-*nix platforms it completely hamstrings the use of native non-POSIX facilities.

Eg. On Win32; the pervasive resource security model; domain based networking; filesharing & range locking;sparse, compressed, encrypted and indexed file attributes; Overlapped IO; much of threading; all of fibres; ... and much, much more; all have to be 'tacked on' as 'after market' extensions (if they can be accessed at all), and so fight with the native Perl facilities instead of complementing them.

To my way of thinking, a truly cross-platform VM needs to be a superset of all platform facilities. And when specified facilities are not available, then either fall back to lesser facilities where possible, or report errors when not.