4.2 BSD Signals: A Proposal

[Guy Harris]

	First, as I understand them 4.2 restarting is exactly like 4.1
	restarting after a new signal feature has been used.  This is
	already a compatibility problem.  Most 4.1 programs I've written
	have used the new interface.

I believe this is correct; the "vnews" we ran on 4.1 used the new signal
mechanism so that it could be suspended, and it turned out that typing
one's interrupt character didn't work like it was supposed to because the
read didn't get EINTR, so I had to stick in a (surprise, surprise) "setjmp"/
"longjmp" pair.

	Also, it has always bothered me that the terminal driver in 4.1 made it
	necessary to do as many as 4 ioctls in order to do logically-connected
	things.  That was a compatibility move too...  Of course, this change
	doesn't using the new semantics clumsy.

This was actually somewhat inherited from V7; the System III/System V handler
cleans this up, although if 4.3BSD or whatever picked up the USG tty driver
and then re-Berkeleyized it they might have to introduce a second "ioctl" to
turn on the local flags and supply the local control characters, which would
bring us back to where we started from...

	ps.  If signal() was kept as a COMPAT system call, and a front-end was
	written to go in a special library (liboldsig?) then use of that system
	call (as opposed to the signal(3) library call) could detect whether new
	or old behavior was wanted, obviating the sigrestartable syscall, just
	as 4.1 detected the use of a new feature and set SOUSIG accordingly.
	I think...

"signal()" is already kept around in 4.2 as part of the 4.1 binary compatibility
feature, and if you issue the "old signal" system call it does, indeed, set
SOUSIG (in fact, that's the *only* place SOUSIG gets set), so your suggestion
has already been implemented in vanilla 4.2BSD if you define COMPAT when you
build your system.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy