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