> 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. The condvar.scm file already serializes its operations, yet still uses without-interrupts, presumably for another reason. I am guessing that the intention is to stave off "aborts" or ANY keyboard interrupt that could eventually throw and leave globally accessible (by threads other than The Aborted One) data structures inconsistent. I have been known to pound with frustration on Ctl-G (repeatedly). Maybe I'm not the only one. If Edwin is going to endure such fits with aplomb, the runtime system it relies on must be wrapping updates with SOMETHING, if not without-interrupts perhaps without-keyboard-interrupts (based on with-thread-events-blocked)? The latter has the advantage that it is easy to see which uses of without-interrupts have been sorted. In the end, there will be no more without-interrupts (except the interesting exception in ffi.scm). Or without-keyboard-interrupts is just needlessly wordy and adds to the size of the SMP patches. In the end, without-interrupts can be changed to use with-thread-events-blocked, allowing thread switching where it will do no harm. Which to choose? There are other issues involved in this reform and they are all discussed in the top-level README.txt file of my SMP branch. For example, object hash tables now have their own mutex while normal hash tables (eq and generic) do not. If you want to have any input into these choices, please make your suggestions sooner. If you like surprises, you can wait until I cry havoc (i.e. "git merge SMP") and THEN make extraordinarily patient, hopefully detailed suggestions. Yours in Scheme, Puck $ git remote add puck git://birchwood-abbey.net/~matt/mit-scheme.git $ git fetch puck SMP $ git checkout puck/SMP $ more README.txt If you look at the commit chain you will see commits that are intended to be squashed into earlier commits. You can correctly infer that at least one more rebasing is on offer. If you want to pitch in, just say so. I will push to Savannah a final rebased SMP from which you can safely branch. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel