Access to kmem - System namelist - 'ps' etc (software interrupts)

[Geoff Collyer]

I beg to differ, Rob.  I used TOPS-10 heavily for five years while in
high school and university.  I think that UNIX does most things better
than TOPS-10 and in particular I don't think software interrupts nor
asynchronous I/O should be grafted onto UNIX.

Berkeley has taken the approach of trying to turn signals into perfect
software interrupts and in doing so has complicated UNIX programs that
wish to use signals correctly.  If you wish to continue is this vein,
then TOPS-10-style software interrupts and asynchronous I/O make some
sense, but please, spare us the control blocks in user address space.

The problem with software interrupts (and thus signal catching) is that
they introduce asynchrony into user processes.  Since asynchrony is a cause
of hard-to-find timing bugs and since it complicates code which exploits
it, I would prefer it to be sublimated into activities synchronous
with user processes.  The Thoth operating system (and more recently Verex
and the V system) provides no form of asynchrony within a process, but
rather provides cheap processes, message-passing and process destruction.
In principle, something happening asynchronously with a process kills the
process, doesn't affect it or generates a message for it.  These mechanisms
have proven sufficient for the tasks undertaken on Thoth and seem sufficient
in general to avoid software interrupts and their associated bugs.

This is somewhat simplified, but I have yet to see a genuine need
for software interrupts, given a Thoth-like environment.
I would suggest the Thoth book to anyone who wants more details
(I think the full title is Multi-process Structuring and Portability:
the Thoth System by David Cheriton, ex of Waterloo, now at Stanford).