[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DYNAMIC-WIND vs. multi-processing
From: firstname.lastname@example.org (Jonathan Rees)
Date: Tue, 11 May 93 13:10:39 -0400
Date: Tue, 11 May 93 10:16:09 -0400
From: Gerald Jay Sussman <email@example.com>
I haven't read the current dynamic-wind proposal
You aren't the only one. DYNAMIC-WIND was not part of the handout.ps
before the last meeting. I have had to write my own description for
SLIB because I couldn't find an official proposal.
..., but I can
assure you that the original reason that Richard Stallman invented
dynamic-wind (in 1980 for the Scheme-81 chip) was to complement
call-with-current-continuation so that each process could have private
versions of certain fluid variables. Without the power of
dynamic-wind we found that we could not support all of the structure
needed to build an operating system.
There is no way I could discern the original motivations from reading
the description in the MITScheme documentation. Just from reading
that description, I have come up with a use for DYNAMIC-WIND which
some rrrs-authors object to (foiling all escapes from a
read-eval-print loop). If DYNAMIC-WIND should be used only for
dynamic binding I suggest that we should either say so in the
description or just scrap it in favor of an explicit dynamic binding
Seriously though, the reason you wanted to use DYNAMIC-WIND to
implement fluid variables in Scheme-81 is that you wanted fluid
variables to actually be implemented as ordinary lexical variables.
In the operating system that I wrote in Scheme, one uses a distinct
syntax to access the value of a fluid "variables", specifically the
(FLUID x) of the Revised Report. With this change, task switching is
accomplished by simply changing the continuation and fluid environment
But this is equivalent to changing the fluid locations on context
switch!! The only difference is that you like deep-binding and GJS
CWCC isn't used for task switching; instead there is a
lower-level operator that is only used internally to the scheduler.
Its action is equivalent to CWCC under the influence of DYNAMIC-WIND.
DYNAMIC-WIND is supported, but the windings and unwindings only happen
when the procedures delivered by CWCC are called, not on task
switching. DYNAMIC-WIND and CWCC have their place, but only within
What you have essentially done is to have 2 versions of CWCC.
Note that this generalizes nicely to the case of multiprocessing (i.e.
multiple processors), whereas DYNAMIC-WIND doesn't: each processor can
easily have its own continuation and fluid environment registers.
That is my point. DYNAMIC-WIND can prevent the state of a process
from being captured by CWCC. A separate primitive construct is
If you believe, as Mr. Jaffer apparently does, that it must be
possible to write a scheduler in portable Scheme, then I would tend to
agree that the low-level non-winding version of CWCC is necessary.
An interrupting scheduler cannot be written in portable Scheme
(because interrupts are not part of Scheme); but that is not the only
paradigm for task switching.
As for a non-winding version of CWCC, it is more complicated than
that; It still needs to wind and unwind dynamic variables but not
I'm not sure I buy that premise, however. It seems pretty useless to
have tasks without pre-emption;
What about co-routines? Everything I said about multiple processes
applies to co-routines.
and if we do adopt pre-emption in some
form, then I think chaos would ensue unless without a standard
interface to the scheduler -- in which case, we should just adopt a
scheduler, not the low-level primitives that the implementation of a
scheduler would need.
There is perhaps more variety in multiproccessing primitives than in
any other area of CS. It will be years before we could agree on a
scheduler (if at all). I am not holding my breath.
CWCC is the marrow of processes. DYNAMIC-WIND, by acting on CWCC,
does not distinguish between escapes, co-routine calls and other
control transfers. I think we will lose a lot of succinctness in the
language if we start distinguishing these.