DYNAMIC-WIND vs. multi-processing

[Aubrey Jaffer <jaffer@martigny.ai.mit.edu>]

   From: jar@cs.cornell.edu (Jonathan Rees)
   Date: Tue, 11 May 93 13:10:39 -0400

      Date: Tue, 11 May 93 10:16:09 -0400
      From: Gerald Jay Sussman <gjs@martigny.ai.mit.edu>

      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
construct.

   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
   registers.

But this is equivalent to changing the fluid locations on context
switch!!  The only difference is that you like deep-binding and GJS
likes shallow-binding.

   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
   individual tasks.

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
needed.

   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
other things.

   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.