Em Ter, 2009-05-26 às 19:33 -0700, Jon Lang escreveu: > "The exact semantics of autothreading with respect to control > structures are subject to change over time; it is therefore erroneous > to pass junctions to any control construct that is not implemented via > as a normal single or multi dispatch. In particular, threading > junctions through conditionals correctly could involve continuations, > which are almost but not quite mandated in Perl 6.0.0." > What is a continuation?
Continuation here is meant in the most generic sense, which is: "The rest of the thread of execution" It doesn't imply any specific API on manipulating the continuations, nor it implies that the continuations are re-invocable, cloneable or anything like that. It basically means that the interpreter can choose to interrupt your code at any point and continue it later, after running some other code. This has the basic effect that Perl 6 points toward *implicit threading* rather than explicit, and also that it points toward *implicit event loop* rather than explicit. In practical terms: sub baz (*...@input) { for @input -> $element { say "BAZ!"; $element + 1; } } sub foo (*...@input) { for @input -> $element { say "FOO!"; $element - 1; } } sub bar (*...@input) { for @input -> $element { say "BAR!"; $element * 2; } } say "BEFORE!"; my @a <== baz <== foo <== bar <== $*IN; say "AFTER"; Is going to open 5 implicit threads (which might be delegated to any number of "worker threads"), besides the initial thread. So, at first, you'll immediatly see in the output: BEFORE! AFTER! The implicit threads are: 1 - read from $*IN and push into a lazy list X 2 - read from the lazy list X, run an iteration of the for in the sub bar, and push to the lazy list Y 3 - read from the lazy list Y, run an iteration of the for in the sub foo, and push to the lazy list W 4 - read from the lazy list W, run an iteration of the for in the sub baz, and push to the lazy list Z 5 - read from the lazy list Z and push into the lazy list that happens to be stored in '@a' That basically means that this lazy lists are attached to the interpreter main-loop (yes, Perl 6 should implement something POE-like in its core), which will allow the read of IO to be non-blocking, so you don't need a OS thread for that. It also means that every lazy list should be somehow attached to that event-loop. So, as you enter data in $*IN, you should get something like that: I entered this line! BAR! FOO! BAZ! I entered this other line! BAR! FOO! BAZ! On the implementation side, I think there is going to be a ControlExceptionWouldBlock, which is raised by every lazy object when the data is not immediatly available, allowing the interpreter to put this continuation in a "blocked" state, somehow registering a listener to the event that blocks it. One of the attributes of the ControlExceptionWouldBlock would be a Observable object, this Observable object is the thing that is waiting for the specific event to happen and register additional listeners to that event. The interpreter itself will register itself as an Observer to that Observable, so it can re-schedule the thread, marking it as "waiting". That being said, I think we have a "continuation pool" which are in either "running", "blocked" or "waiting" state. And a scheduler that takes this continuations and assign to the "worker threads", while you can use a command line switch to control the minimum/maximum number of worker threads as well as the parameter for when to start a new worker thread and when to deactivate it... Well, this is my current view on the state of affairs, and is thougth a lot in the context of SMOP, so it would be really interesting to have some feedback from the parrot folks... daniel