


    It is true that WITHOUT-INTERRUPTS could mean a number of things,
but that doesn't mean that it has no place in portable code.  The
primary use is in protecting code which modifies data structures so
that the update appears atomic as far as the user is concerned.  No
matter where he types ^G, the data structures of his program won't get
trashed.  Although Common Lisp doesn't require asynchronous interrupts
from the user, any reasonable implementation will have them, and good
software must deal with that fact somehow.

    Note that Common Lisp only defines a single-thread environment,
thus the behavior of WITHOUT-INTERRUPTS in a multiple-thread Lisp
implementation wouldn't be a proper part of its Common Lisp
specification.  In a multi-thread environment, it should probably freeze
out all other threads during the execution of the body.  This makes it
very expensive in a multiprocessor, and therefore probably useless,
but then nobody ever said that writing software for a multiprocessor
was easy.

    I believe that the Lisp machine interpretation is about right,
although it is silly to talk about "inhibiting scheduling" in a
single-thread implementation.  WITHOUT-INTERRUPTS shouldn't have
anything to do with real hardware interrupts, it affects "software
interrupts".  Although some systems might get upset if you ran without
interrupts for minutes, programmers who use WITHOUT-INTERRUPTS
in a "reasonable" fashion shouldn't have to worry about trashing the

    WITHOUT-INTERRUPTS should nest properly, which means that
	(without-interrupts xxx)
can't turn into 
	(interrupts-off) xxx (interrupts-on)
Spice Lisp (and Zetalisp, I believe), implement WITHOUT-INTERRUPTS by
binding a special variable which the low-level interrupt handling
mechanism looks at before deciding to actually service an interrupt.