🚀 go-pugleaf

In article <6812@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes:
>*any* intelligent I/O subsystem will have to keep some sort
>of internal data structures, and an interrupt routine will
>immedeately blow the program away as soon as it tries to do
>I/O. Or, even worse, it will blow the program away two years
>later, when you've long gone somewhere else.

Well, if one can implement an atomic semaphore (I know how to
do this for a PDP-11 or a VAX), one can implement "conditional
critical regions" to protect data structures from being clobbered
by asynchronous interrupts.  The 3B20A UNIX kernel uses semaphores
for this purpose (it's the only symmetric multiprocessor implementation
of UNIX that I am aware of).  SVR2 STDIO makes a valiant attempt to
permit use of STDIO routines from interrupt handlers.  However, ...

>The only safe things to do in an interrupt routine are
>- setting the InterruptHasOccurred flag,
>- longjmp
>- exit.

... I agree with these sentiments, mostly.  I wouldn't even say
that longjmp is safe, since while the (non-interrupt) manipulation
of data structures is occurring, they will be in an inconsistent
state that could cause trouble later if the manipulations are not
allowed to complete.

To implement operating systems, however, the problem of asynchronous
interrupts must be solved.  Methods for parallel processing have
been published in the past decade or so that are relevant to this
issue.  Ultimately one needs an atomic synchronizer and a queue
to put blocked tasks on when they attempt to enter a locked region.
(A blocked task is allowed to proceed when the locker leaves the
shared region.)  This seems like far too much complexity for normal
user-mode applications, though, unless implemented as a package or
class (probably with a small assembly-language locking module).