Re: Parrot, threads & fears for the future.

Does the
complete absence of a threads.pdd from the specification;
that the term "threads" appears only 35 times in the entire documentation set;
that the "failed" ithreads model so widely denigrated and despisedis being nearly exactly replicated for the underpinnings of the new language;

inspire you with confidence?

the above statements are incorrect. parrot has a threads design document. see http://www.parrotcode.org/docs/pdd/ for the list of design docs, and note threads (pdd25) is there, and is clearly labeled as a draft. it is not completely absent.

parrot's threading spec has not yet been redesigned, since originally conceived. as it was conceived some time ago, it's bound to look out-of-date, especially as when it was conceived, perl6 looked a lot more like perl5, so it's natural that the model looked a lot like ithreads.

parrot work is in progress--currently the exception model is on the top of the design list, followed by threads and i/o (however, i'm not sure of the specific order of those two.) allison's last commit (two weeks ago) to the threads doc has a log that reads, "Partial update of Threads PDD with collected wisdom from prior discussion."

as an aside, for those of you who have not seen me around here lately, i've been devoting my free time to work on parrot rather than to hang out here. i'm responsible for the parrot test suite, and am having a blast and learning a great deal by working with patrick michaud on the perl6 compiler as well. i wish you'd all join the parrot-porters@perl.org mailing list and contribute to any discussion where you feel it appropriate. parrot has made major progress in some respects (it has fully specified and implemented namespace and lexical implementations to name two,) but it's success depends almost solely on the contributions of volunteers. if you feel you have something to add to the components of parrot which are still in draft status (like threads,) please don't hold back.

~Particle *accelerates*

Comment on Re: Parrot, threads & fears for the future.

Replies are listed 'Best First'.

Re^2: Parrot, threads & fears for the future.
by BrowserUk (Patriarch) on Oct 23, 2006 at 18:31 UTC

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.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]


We don't bite newbies here... much
	PerlMonks