signal handling in 4.2: Is this - (nf)

[Dave Mason]

<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

Rob Warnock replies:
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
....

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
....

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.
....
Rob Warnock ...!fortune!rpw3

I agree with Rob, real software interrupts are usable to build higher
level primitives (after all real hardware interrupts ARE used to build
higher level primitives), but that doesn't mean that they are the right
approach.  In particular the question that it doesn't address is providing
information about co-operating tasks to the operating system so that it may
be able to improve the scheduling.  It also means a fair amount of hacking
to build the higher level primitives.  And it doesn't address civilized I/O
by the co-op tasks.

The right solution requires looking at how the O/S is implemented..shareable
address space & synchronization primitives & private I/O.  Those are the
facilities that the O/S should be providing to the user tasks.  The problems
are in how to combine this with security for the user tasks & the O/S itself.

My approach is to make address space & process-hood independent, and to make
address spaces tree structured.   Processes being independent of the address
space means that you can use things like Concurrent Euclid to solve real
problems requiring concurrency within the confines of an O/S.  Each process
can execute independently (using multiple processors if available) doing I/O
etc. and synchronization is handled by the O/S knowing about monitors &
conditions.  The tree structured address space is used to facilitate
interactions between unrelated processes (a little detailed for this note).

I won't argue semaphores/monitors or monitors/messages, but I personally
feel monitors are the right way to go.  Hopefully others will implement
these kinds of facilities for user tasks using these alternate approaches.

-- 
 Dave Mason, U. Toronto CSRG,
	{utzoo,linus,cornell,watmath,ihnp4,allegra,floyd,decwrl,
	 decvax,uw-beaver,ubc-vision}!utcsrgv!mason