[MIT-Scheme-devel] Symmetric MultiProcessing

[Friar Puck]

> From: Friar Puck <address@hidden>
> Date: Mon, 23 Feb 2015 16:01:13 -0700
> 
> > From: Friar Puck <address@hidden>
> > Date: Sun, 21 Dec 2014 13:03:25 -0700
> > 
> > [...]
> > 
> > Encouraging results are just what SOMEONE needs when going in the ring
> > with up to 104(!) possible demons in the guise of without-interrupts.
> > And that's just the runtime system.
> 
> As The Reformation grinds along, I find that without-interrupts is
> used for a couple of reasons.  I am looking for uses intended to make
> multiple side-effects "atomic" from the point of view of other
> threads, and replacing them with explicit serialization via new thread
> mutexes.

I have re-based and re-arranged my SMP branch, moving The Reformation
to the beginning of the chain and pushing it into master.  Without-
interrupts is therewith banished from the runtime system (outside of
thread.scm and a handful of other applies).  The only user visible
changes THIS time were the disappearance of two related variables:

        *save-uncompressed-files?*
        *uncompressed-file-lifetime*

I punted the uncompressed-files cache.  If some ancient hardware
really needs it, you know where to scream.  (I was tired and feeling
under-motivated. :-)

There is still plenty of rope out there for those intent on injuring
themselves.  For example I did not add a thread mutex to every
interpreter environment.  Two concurrent threads can extend the same
top-level environment and get unexpected results.  (Maybe SOMEONE
should lock down load-option? load? eval?!)

MOST data structures (including strings, vectors, flonums, hash
tables, random states, subprocesses, and generic functions) should not
be concurrently modified.  I've only banished without-interrupts and
locked up behind-the-scenes data like the default-random-state and the
default object-hash table.  (Actually, I locked up ALL object-hash
tables.  Now that I've [re?]read the documentation, I wish I hadn't.)