[pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless

[Armin Rigo]

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.