[pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
arigo at tunes.org
Wed Oct 19 13:26:30 CEST 2005
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
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.
More information about the Pypy-dev