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? _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel