threads & dynamic environment & continuations shivers@xxxxxx (12 May 2000 01:20 UTC)
Re: threads & dynamic environment & continuations Marc Feeley (12 May 2000 01:55 UTC)
Re: threads & dynamic environment & continuations shivers@xxxxxx (12 May 2000 18:14 UTC)
Re: threads & dynamic environment & continuations Marc Feeley (12 May 2000 18:38 UTC)
Re: threads & dynamic environment & continuations shivers@xxxxxx (12 May 2000 18:44 UTC)
Re: threads & dynamic environment & continuations Matthias Felleisen (12 May 2000 02:46 UTC)
Re: threads & dynamic environment & continuations shivers@xxxxxx (12 May 2000 02:58 UTC)

threads & dynamic environment & continuations shivers@xxxxxx 12 May 2000 01:20 UTC

On the whole, I like Marc's design very much. I would like to comment on
the interplay between threads, dynamic environments and continuations.

Essentially, a continuation is a snapshot of thread state. Think of a thread
as a virtual PC. Throwing to a continuation loads that PC's context.

It is well understood in the SML/NJ community (which has been grabbing
continuations, dealing with dynamically bound exceptions, and hacking threads
for > 10 years), that the dynamic environment is *part of the continuation*.
So throwing to a continuation discards the current dynamic environment, and
installs the one packaged up with the continuation to which we are throwing.
CALL/CC grabs the dynamic environment at the point of call and packages it up
when it builds the reified continuation.

Finally, you need to add some kind of
    (call-terminally thunk)
or
    (call/null-continuation thunk)
procedure to allow one to *drop* the dynamic environment in order to prevent
space leaks in some thread cases. Such a function calls THUNK with a
continuation that (1) either kills the process or is undefine and (2) has no
dynamic environment. That is, *don't* return through that continuation. It's
only purpose is to sever ties with the current continuation (i.e.,
CALL-TERMINALLY's continuation).

I don't believe the spec states the (obvious) fact that preemptively switching
between two threads, or yielding or otherwise blocking does *not* cause
DYNAMIC-WIND's to fire. (By the way, I think DYNAMIC-WIND is a very bad idea,
in general. I opposed its introduction because of its bad interaction with the
notion of thread concurrency, and here we are, tripping over it.)

I think the current document should state these things explicitly. To sum up:
    - dynamic env is part of the continuation,
    - hence, throwing to a continuation changes the dynamic env.

There has been some discussion about the merits of keeping or dropping
continuations at all. I *strongly* support keeping continuations in Scheme.
They are an important conceptual and programming tool.
    -Olin