RE: NQP.
BrowserUK wrote:
I take that to mean, that despite the context and the second half of the sentence, the "prototype" mentioned is some kind of Perl 6 language prototype, and not any kind of Parrot threading prototype.NQP is "just another language on top of parrot".... like TCL or basic. It's an extremely small subset of perl6 with much a stricter grammar. If I'm reading the meeting minutes correctly it serves a few purposes:
RE: parrot concurrency
That leaves just the existing PPD ... is based upon the Perl 5 iThreads model;Are we reading the same document?
The PDD describes internal and external (HLL) constructs required for concurrency. They mention two distinct HLL APIs: "shared everything", and "shared nothing". (They're also supporting "completely independent" threads).
The PDD says that the schedulers will manipulate Task PMCs (which describe priorities, constraints, and keep stats?) in order to co-ordinate interpreters and interpreter pools.
User-level PMCs will be the standard PMCs in "shared nothing"; PMCs will have their vtable replaced in "shared everything" such that (internal, ordered) locking of parameters is enforced for PMC method calls.
It looks like they're only sharing PMCs (not small enough for hardware-level atomicity but small enough to be done efficiently)... not externs or strings of bytes. That would imply that HLL compilers organise marshalling of user-level data-structures.
If I read it correctly, a pool of "shared everything" threads will be implemented as a pool of "shared interpreters" implemented in a lightweight manner over plain POSIX threads. Different vtable methods on the (shared) PMCs will support access to either pool-wide or thread-local PMCs.
In the "shared nothing" model they seem to be saying that they're going to implement it on top of the "events" APIs they've marked out in an earlier PDD.
It says that there will be thread-specific and (interpreter) pool-specific event queues and that events will be guaranteed to post in the target thread (and in the "correct" order). At this level what they describe sounds a lot like the way Erlang implements its message-passing for lightweight processes.
[the PDD?] was written by people who had never used that model; makes no concessions to the obvious failures of the only existing implementation of that model; seeks to perpectuate all the mal-features of that modelWell I can't speak as to the "who", but I just don't see how you get to that conclusion. The features described in the PDD are very low-level and could be used in a great many ways by HLLs (such as perl6, tcl and Python). I can't find one place where they (at parrotcode... or the perl6 design team for that matter) say that they're going (overall) for anything like iThreads; rather I see plenty of examples to the contrary.
In the parrot concurrency PDD it says they must "support" something like iThreads for HLLs, but in reading about the APIs they're providing it seems that an iThreads-like model is only one of many possible HLL concurrency models you can build on parrot's APIs.
As an example iThreads could be implemented by an HLL compiler writer (say for per5-on-perl6) with the "shared nothing" parrot APIs. It (like perl5's threads.pm) would need to copy non-shared data to remain API-compatible.
That doesn't stop any HLL designer from building a myriad of other concurrency models over either (or both) of the parrot -supported concurrency models. An HLL compiler could provide POSIX-like, Erlang-like, Java-like or invent-your-own models of concurrency. IIUC it looks like a very broad-minded design.
[concurrency?] will have to be tack-on to the Parrot single tasking architecture after the fact just as the existing implementation was.I also don't get that impression at all. It seems to me like they're creating a very broad set of possibilities for a variety of HLL compilers (perl6 not being special). I just can't understand how you can say that given the discussion in the PDD.
I'm going to have a closer look at the group archives and meeting minutes to gauge the progress for myself, and to see if anyone's talking about straying from what they've talk about in the PDDs... but on the face of it, I don't see any reason to be pessimistic about it.
I don't see why the parrot team shouldn't continue to work on parrot in an order that seems appropriate (to the parrot developers) while keeping in mind the constraints and decisions implied in the concurrency PDD. It's something that I do all the time in projects, and something which (as you mentioned) can be greatly aided by regression testing.
perl6 concurrency:
Now here's where I start to share your concern (but probably coming from a different tack). The perl6 concurrency DRAFT spec is at an extremely early stage of progress. One could argue (as you have) that it's extremely important to get it correct from the beginning. I don't know what steps have been taken so far by the perl6 team (as distinct from the parrot team).
I for one am concerned about the focus on STM (but that may turn out to be a non-issue... I'll wait to see what Elizabeth et al come up with). I'd wager that there'll be many, many Perlmonks meditations and questions on perl6 concurrency as the implementation starts to fill out... I believe we'll have ample opportunity to discuss that progress at a later date.
-David
In reply to Re: Slow evolution of Perl = Perl is a closed Word (NQP, parrot concurrency == Oh dear.)
by erroneousBollock
in thread Slow evolution of Perl = Perl is a closed Word
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |