> From: Friar Puck <p...@birchwood-abbey.net>
> Date: Mon, 23 Feb 2015 16:01:13 -0700
>
> > From: Friar Puck <p...@birchwood-abbey.net>
> > 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.)
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
