4.2 BSD Signals: A Proposal

[mike%rice at sri-unix.UUCP]

From:  Mike Caplinger <mike at rice>

[This message has a possibly worthwhile suggestion at the bottom.
Readers interested in skipping the rest can feel free to do so.
- Mike Caplinger]

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'm really scared of making any changes to 4.2 that don't make it into
ALL the distribution tapes that are going to be sent out.  I like
Mike's solution, but do you really think it's worthwhile trying to do
such things in the name of portability?  I believe the following
things:

1) There will be many 4.2 programs that will never run under Sys V.
2) There will be many Sys V programs that will never run under 4.2.
3) Most educational sites will never run Sys V on VAXen.  We would only
   run Sys V on any machine if we were stuck with it.

Experience with the millions of local hacks that ran around under v7,
and trying to cope with /usr/group and Usenix software that used them,
has made me very wary of local hacks.  I suspect there will always be
purists who refuse to implement local hacks; I even think I'm one of
them.

I wonder if, now that rumors say Berkeley isn't really doing
development work, we might get people there to listen to improvements
like yours.  How about Ultrix?  Will DEC listen?

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.

I guess what I would like is for the change to be added, but controlled
by the COMPAT #ifdef.  Good luck lobbying for it!

		- Mike

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