[MIT-Scheme-devel] Symmetric MultiProcessing

[Matt Birkholz]

I just branched from master with the following commit message.

    Add configure option --enable-smp.

    Arrange for multiple Scheme machines, "processors", (pthreads) to
    share the heap.  Each gets its own stack and "local" heap areas.
    Gc-flips trace the stacks and evacuate the local heaps into the shared
    heap.  The dump-band primitive now works like half a gc-flip,
    evacuating the local heaps and saving the shared heap to disk before
    the primitive gc daemons can start consing in a local heap again.

    The garbage collector and thread system are working with ONE
    processor.  Still to do:

        Run multiple processors running multiple threads and
        cooperating to GC.

        Serialize access to shared C variables like channel_table.

        Review uses of without-interrupts, which no longer produces a
        globally atomic section.

        ???

It's not fancy, but it works.  One processor runs the garbage
collector while the (purely theoretical) others wait.  To check it
out, fetch the SMP branch from:

        git://birchwood-abbey.net/~matt/mit-scheme.git

I am writing to y'all now because soon I will have to do something
about fluid-let.  I appreciate that we can currently fluid bind any
binding and access it from compiled code without penalty (as quickly
as any free variable access), and that the implementation shares the
state-space abstraction used by dynamic-wind, and all that BUT... that
will not work when multiple machines share bindings simultaneous-like.

If we want SMP(?) and don't want it in a distant fork, we might just
bite the bullet and replace our fluid bindings with fluid objects
(like e.g. s48's).  That's an assq on each reference but the thread-
local values are stored and accessed in a straightforward manner, and
there is no winding and unwinding in state-space:global at every
thread switch.

The changes I've made so far are fairly small (circumscribed by #ifdef
ENABLE_SMP) but the changes required to replace fluid-let with fluids
will impact the syntax of every reference to a fluid-bound variable...
unless there is another solution?

Did MultiScheme implement fluid-let?  Whither MultiScheme?