signal handling in 4.2: Is this - (nf)

[rpw3 at fortune.UUCP]

#R:hou3c:-13500:fortune:11600038:000:4564
fortune!rpw3    Jan  3 12:15:00 1984

<non space>
	***** fortune:net.unix-wizar / utzoo!henry /  4:20 pm  Dec 20, 1983
	While I fully agree with Rob Warnock that signals are not software
	interrupts, that they were never intended as such, and that anyone
[1] ->	who uses them as such is insane and deserves what he gets...  May
	the gods preserve us from people who think real software interrupts
	are wonderful and desirable!!!  Why do you think the first act of
[2] ->	practically every decent operating system in existence, when it gets
	an interrupt, is to turn it into something more civilized (e.g. a
	wakeup or a semaphore operation)?  Interrupts are an ugly, low-level,
	terribly error-prone form of communication.  I agree that Unix could
	use better interprocess communication (and that signals were never
	intended to be such), but real software interrupts are the *last*
[3] ->	thing we want!  Higher-level primitives, **PLEASE**!
	-- 
					Henry Spencer @ U of Toronto Zoology

The Concurrent Euclid model is indeed one of my internal refence models
when thinking about such things (c.f. Holt, R. C. "Concurrent Euclid,
The UNIX System, and Tunis", Addison-Wesley 1983). As part of a performance
analysis task, we implemented a Euclid-style "simulation kernel" which allows
multiple "processes" in one UNIX-process (c.f. Bakul Shah's articles on
"nargs()").  It works just fine doing Simula-like simulations, but when
you start hooking it to the outside world what happens? You need REAL
INTERRUPTS as the thinnest, bottom-most layer of the structure to drive
your semaphores (actually, priority condition queues).

Please understand the constraint of more-or-less "standard" UNIX.  In
terms of your note, I am TRYING to impose higher-level primitives [3],
as as fast as I can [2], and may well be insane [1] to expect to be
able to do it easily under UNIX.

Unfortunately, standard UNIXes do not allow multiple processes to
share easily and completely the same address space, as is needed for
efficiently implementing semaphore-based multiprogramming (not even
System-V, really).

Clean software interrupts ARE a useful basis for higher-level
primitives; other operating systems have provided them to users. When
complete soft-int's are provided, the code gets CLEANER, since you can
handle each interrupt as a "message" from the operating system that the
world is changed in some interesting (to you) way. (In fact, on some
systems, soft-ints are solely used to handle messages.) However, no
commercial UNIX I know of treats kernel events as messages to the user
process. (I believe there was some CMU experimental work that treated
ALL system calls and returns as messages, which would be completely
equivalent to the software interrupts I suggested.)

It has even been noted that the two most common styles of operating
systems, the procedure-call/monitor model and the message-passing
model, are in fact completely equivalent.  [Lauer & Needham, "On the
Duality of Operating System Structures", Operating System Review v13 #2
(Apr'79) pp3-19]. It was noted that attempts to do both generally
were quite messy. UNIX and Euclid both fall in the prodecure-call/monitor
camp, and I suspect efforts to graft messages on without clean interrupts
will result in further hackery.

The 4.2BSD "select" is insufficient, NOT because of the basic style
of the mechanism, but because it does not go far enough. I would be
almost satisfied with a "select" instead of "software interrupts" if
the "select" could return a "completion code" for ALL of the events the
program needs to know about: child died, <DEL> hit, timeout expired,
read complete, write complete, packet sent, IPC received, etc.
("Select" still doesn't allow the process to run CPU-bound while
handling I/O in the "foeground", though. I believe that the user process
should also have some say in how its background scheduling is handled.)

In summary, the definition of "civilized" [2] depends on where you
stand. Current UNIXes do not allow you do do a wait-for-any-interesting-
condition. It is not clear to me that the pure semaphore model (one of
several reputable models) fits well into UNIX. A clean software
interrupt system or a complete message system might be better.
My vote (currently), based on the amount of work and on upward/downward
compatibility issues, is for clean interrupts. Given that, the other
mechanisms can be built as wanted/needed.

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065