4.2 progressive or dead end - (nf)

[rpw3 at fortune.UUCP]

#R:sask:-3400:fortune:11600088:000:3667
fortune!rpw3    Apr 15 23:01:00 1984

As I said here back in December, the problem is that UNIX "signals"
just ARE NOT either decent software interrupts or decent condition
handling primitives.

Certainly we aren't going to accuse the fine Berkeley folk of trying
to do us deliberate harm; tehy attempted to deal with the limitations
that arise (especially in a network environment) when you try to do
something with signals besides use them to abort processes completely.
The problem is that the underlying UNIX semantics are just WRONG. Now
4.2 chose to try and provide one corner, which isn't the corner we have
all grown accustomed to, so peoplw are screaming. But BOTH the old way
and the 4.2 way are just make-do. They are both partial approaches due
to the fact that UNIX signals do not permit "unwinding", but only "longjmp".

If you think that dealing with UNIX signals from the USER side is fun
and games, try doing anything new in the kernel and watch the world
break. You call an innocent kernel support routine which does a "sleep"
at positive priority (o.k., say you DO want the sleep interruptable),
and a signal comes and blows the process away leaving locks you have
set because YOU NEVER KNEW THE LONGJMP HAPPENED!

Yes, USG 5 lets the code that does the sleep say whether signals longjmp
or not, but how is that code to know that the CALLER of it wants to know
we are "unwinding"?? The immediate sleeper can clean up, but how about any
other routines up the call tree? (And what about UNIXes that haven't gotten
around to adding even that? Makes it virtually impossible to maintain any
monitor assertions.  ARRGGHH!

Yes, it is possible to use the UNIX ("C", really) "longjmp" as a primitive
out of which a decent stack-unwind can be done. But no-one has! (I did just
a toy example to show it could be done.) The longjmp mentality is sprinked
all over the place. It is going to be a major effort to clean up the kernel,
which is (sorry to say) where the problem lies.  The manifestations of that
problem in user mode are just the tip of the iceberg.  I dare say, even with
the new hacks in the process exit code, that there will be found MANY ways
to "hang" the new sem/msg/shm features in USG 5.  Once users start banging
on those features in ways not anticipated by USG (especially with networks
and lots of signals), we will begin to hear complaints about Sys-5, too.
(Just a guess.)

Without flaming on all night, let me simply refer you to two examples of
adequate primitives. Neither is completely "pretty", but both (especially
the first) offer better models than the current UNIX "signal":

1. Vax architecture condition handling. Read ESPECIALLY what happens
   to intermediate condition handlers (like, they get called, NOT jumped
   around!) when a "stack unwind" (a "longjmp" that works) happens.
   (Ref: Vax Architecure Handbook, DEC, 1981, Appendix C., Sections 4, 9-12)

2. TOPS-10 Software Interrupts. A complete facility allowing interrupting
   a user process on practically any interesting event (including system
   calls!). Almost mandatory for reasonable multi-device non-blocking I/O.
   (Ref: TOPS-10 Monitor Calls, Vol. 2 DEC AA-K039A-TB, August 1980,
   applies to TOPS-10 version 7.01)

The usefulness of the TOPS-10 modem is that it was added on BESIDE an
already existing set of functions that bear a striking resemblance to
current UNIX signals. The original functions were left untouched, so
old programs got the same behavior. I believe it is possible to do the
same to UNIX.

Rob Warnock

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