Re: Threads and asyncs

[Tom Lord]

        > I would like to specify explicitely that marking a system-async will
        > run its thunk in the thread that did the marking.


Why can't that be layered?

In other words, start with thread-independent asyncs (which have the
virtue of simplicity and speed) and then build thread-specific on top
of that (at additional cost).

Is there no use for thread-independent system-asyncs?

There is a definate design tension trying to model stack-based,
kernel-driven execution in Scheme.

I've often considered layering call/cc for that reason -- making it
strictly optional, perhaps with a modest performance penalty,
implementing it via a transformation to continuation passing style.
One difficulty is primitives that call apply or eval: you can do away
with them or give them their own threads or mirror them in
tail-recursive scheme (somehow).

There are other alternatives, such as radical changes to the execution
model, so that C stacks aren't used by Scheme at all.  In my personal
Scheme design, this is the route I've (more or less) decided on.  When
worked out, and made to work cleanly with primitives written in
"classic C style" (i.e., freely calling eval or apply), I think it
winds up converging on more-or-less the same solution as making
call/cc work by transformation to CPS.

Anyway, where I to hack Guile, I'd look into building up the
abstractions to a point where eval is potentially a stackless graph
machine, instead of a hybrid stack/graph machine -- but preserving
optimizations such as SCM's copying-gc for environment frames.

-t