Hi Christian, First of all a general comment: I did two unrelated things yesterday about Stacklessness and I think you are confusing them. I did a tiny naive app-level MixedModule to expose a few basic functions just to play around (I'll remove it if it causes confusion). The interface I described in the text file, on the other hand, is at a completely different level. I never planned to expose it to app-level programs. Its only goal is to be as minimalistic as possible, i.e. to allow us to write as few C code as possible, while giving RPython programs some "good enough" way to control its execution. That interface is *not* meant to be exposed anywhere. I'd discourage anyone from using it from RPython and certainly not expose it to app-level. It's meant to build something else on top of it, as a MixedModule. Of course I'd go for something with a greenlet interface. It could also have directly a tasklet interface (which would give a good performance, better than writing tasklets on top of greenlets at app-level). So once again the only goal here is to enable such things to be built, not to be directly used. (For that matter, greenlets are still bit like that: slightly too low-level to be directly useful. Tasklets are a much more practical interface.) On Wed, Oct 19, 2005 at 03:01:07AM +0200, Christian Tismer wrote:
* The built-in function ``yield_continuation()`` causes the current function's state to be captured in a new ``continuation`` object that is returned to the parent. Only one frame, the current one, is captured this way. The current frame is suspended and the caller continues to run.
Thhis is a problem, since this extra state is potentially able to re-run its caller twice.
No: the explanation is in the next paragraph, which was indeed not too clear. Here it is with other words: * the function that called ``yield_continuation()`` also has a normal return statement, like all functions. This statement must return another ``continuation`` object. The latter is *not* returned to the original caller; there is no way to return several times to the caller. Instead, it designates the place to which the execution must jump, as if by a ``switch()``. The place to which we jump this way will see a None as the source continuation.
* every continuation must be resumed once and only once. Not resuming it at all causes a leak. Resuming it several times causes a crash.
I understand the only once. But why the leak issue? We have its state, why don't we allow to collect?
It's a whole can of worms; we would for example like to run finalizers etc. This requires raising an app-level exception like TaskletExit. It's comletely out of scope of this level, so it's best handled by whatever is built on top of these "continuation".
These continuations are one-shots in the first-place, which isn't obvious.
I think it's still correct to call them continuations, but I'm open to suggestions for a better name. If the name suggests it's an internal implementation basic block, the better.
If I would expose this interface, then I would make it full-continuations, and have the full catastrophe.
I guess you see my point by now. Full continuations are far more advanced beasts from the C point of view -- duplicating frames requires more knowledges about the frame structures that we produce right now and comes with all the same management problems that never resuming a continuation creates. It's easy to delegate the latter problems to a higher level, but not the former ones.
I don't really see the need to expose these at ll-level. What people want is to be able to spawn a seperate Python no-thread.
That's easier to write in Python than in C, hence this interface. A bientot, Armin.