Specials/Stacks

[William.Lott@ARDATH.SLISP.CS.CMU.EDU]

Scott writes:
> The document needs to say explicitly what happens with Lispy environment
> stuff when threads get switched.  I guess special variables is the only
> thing we need to worry about.  A lot of Lisps, when they go in heavily for
> stack-groups, switch over to deep binding for specials, but we'll probably
> want to stick with shallow binding and do the wind-unwind when stack-groups
> are switched.  Even if we have an "exit this thread and don't do
> unwind-protects" option, we still need to restore the specials.

I had planned on using MACH's thread support.  This means that we have
little control over when threads are switched, and no way to do extra stuff
like re-binding specials when they are.  But it means that we don't have to
worry about starvation and that we could utilize multiple processors on a
multi-processor machine.

In my opinion, the starvation issue is enough to warrant use of MACH
threads.  I've used both preemptive and non-preemptive threads packages in
C.  Other than the fact that C debuggers can't deal well with preemptive
threads, they are much easier to use.  You don't have to worry about what
library routines or system calls might block, because if they do, it's just
your thread that is blocked, not every thread.  Besides, we're going to
have wizzy debugger support for multiple threads, so that won't be an
issue.

Rob and I have discussed this, and it seems the only sane thing to do is to
have special bindings thread specific.  Given preemptive scheduling, we
have to use deep binding.  But we've also discussed several tricks we can
do to optimize lookup, etc.  It shouldn't be too bad.

-William