Re: about coroutines

[Marius Vollmer]

Keith Wright <address@hidden> writes:

> Conservative GC needs a little help from the C compiler that is not
> strictly required for C.

Hmm, the traditional reasoning is that even of there are spurious
references in the stack, they don't really hurt since the stack is
finite and so you get only a finite amount of uncollected garbage,
provided that you only have finite data structures.  That is, the
conservatism of the GC can only enlarge your memory requirements by a
constant factor if your stack is bounded.  More over, experience shows
that the constant factor is small.

In our case, with stack-copied continuations, this reasoning can not
be applied, since the stack itself can grow due to spurious
references, which gives us an possibly unbounded stack with possibly
an unbounded number of spurious references.

> [...] For example, the C spec requires uninitialized variables to be
> zero, [...]

This is only true for global variables, local (automatic) variables
are not guaranteed to be initialized to zero.

> mvo> I don't know.  The continuation is referenced from a cons cell that
> mvo> was passed as an argument to a function.  After that particular piece
> mvo> of code (eval.c:2906), 
> 
> Is that a line number?  In my version of eval it doesn't seem to
> point to anything interesting.

Yes, it's this line

          env = EXTEND_ENV (SCM_CLOSURE_FORMALS (proc), scm_list_1 (t.arg1),
                            SCM_ENV (proc));

t.arg1 is the argument to call/cc, which is a continuation in our
case.  The return value of the call to scm_list_1 sticks in the stack.


> RnRS> Programming languages should be designed not by piling feature
> RnRS> on top of feature, but by removing the restrictions that make
> RnRS> additional features appear necessary.
> 
> We already have throw with catch and lazy-catch for continuations
> that are used only in restricted situations, and coop-threads seem
> like coroutines by any other name.  I'm just not happy to see more
> half done continuations.

Yeees, but.  One also needs to make compromises for practical reasons.
The module system needs support deep in the implementation, for
example, and the Scheme reports don't even talk about error handling,
something which I consider very important for a practical programming
language or system.

Continuations in the presence of dynamic-wind can't really be used to
implement multi-threading, I'd say.

One-shot continuations have been considered for performance reasons, I
think.  We would add that they help with conservative GC and stack
copying, too.

But we should probably better try to rid us from the drawbacks of
conservative GC...