[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

threads & dynamic environment & continuations

This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.

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)
    (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.