Re: thread design

[Scott.Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU]

William,

It looks good, mostly.  Let me echo the suggestion that you look carefully
at Lispm and Lucid (and Allegro?) stack groups just to see if anything is
missing.  I've got some of the relevant manuals.

I have no strong opinion on whether we should use Lispm-like nomenclature
or C-threads nomenclature.  I guess it depends on which set of immigrants
we want to accommodate.  One point, however: you can't use the term
"condition" the way you have it documented here, since "condition" is
already used by Common Lisp to mean error-system conditions.  The concepts
are related, but I think not the same.  Maybe they could be made to be the
same?

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.

BTW, I think that separate functions might be the way to go for "politely
exit this thread, observing unwind-protects" and "emergency exit".  The
latter might well screw up the outer Lisp, leaving things in some evil
state, so it should only be used if all else fails.  Maybe it should only
skip over one unwind-protect, and you call it repeatedly if you need to
crawl out of nested traps.

-- Scott