[net.unix-wizards] signal handling in 4.2: Is this still UNIX?

ian@utcsstat.UUCP (Ian F. Darwin) (11/30/83)

So signal handling is radically broken. The file system is different.
The shell is different. The manual is humungous. The commands have
many gratuitous changes.

Is this still UNIX? Perhaps we should all start calling it Berklix
(a registered footnote of the Regents of the University of California)
to emphasise that, be it how nice it may, it's no longer the UNIX
that we once knew and loved.
-- 
Ian F. Darwin, Toronto		uucp: utcsstat!ian

thomas@utah-gr.UUCP (Spencer W. Thomas) (12/04/83)

So they "broke" the signal handling in 4.2.  Assuming that the new
implementation is correct (i.e., bug-free), I like it better.  It
certainly more closely models interrupt handling.  You wouldn't expect a
hardware interrupt to kill off your system call, so why should a
software interrupt?  If you really want to quit out of whatever was
going on, then use longjmp.

=Spencer

henry@utzoo.UUCP (Henry Spencer) (12/06/83)

To paraphrase Charles Lindsey:

	"C'est magnifique, mais ce n'est pas Unix."

(For those of you who don't read French:  "It's good stuff, but it
sure isn't Unix.")
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

ka@hou3c.UUCP (12/09/83)

Come on, Spenser.  Hardware interrupts don't interrupt system calls
because user programs have nothing to do with them.  The PDP-11
provides, and the kernel uses, a wait instruction which is term-
inated by an interrupt.

I don't want to quit out of "whatever is going on"; I want to quit
out of a read if the user types an interrupt.  Yes, it is possible
to use longjmp, but the resulting code will be convoluted and
difficult to maintain.  Remember that if an interrupt arrives while
another signal is being processed and the interrupt handler does a
longjmp then the other signal handler will never be completed,
so that kludges have to be devised to make these signal handlers
work properly even if they are chopped off in the middle.  Not
very easy to do.

Actually, my biggest objection to the change in signal handling is
that it is different from other UNIXes.  I am not saying that
Berkeley shouldn't be making improvements to UNIX.  But this
change provides no new functionality.  It makes it unnecessary
to check for interrupted system calls, but if the program is
to be portable to other versions of UNIX, the checks have to
be included anyway.  If being able to share software between
systems is important, then Berkeley's change to the signal mechanism
is a bad idea.
				Kenneth Almquist


* UNIX is a trademark of Bell Telephone laboratories, Inc.