4.2 signals broken?

[Guy Harris]

A few amusing bits, found from poking at the 4.2 code:

1) If you compile in the binary compatibility feature of 4.2, the old
"signal" system call is left in - if it is used, the 4.1 behavior for
interrupted system calls (which, I believe, is the standard V7/S3/S5
behavior) is preserved.  So there are hooks for the old way.

2) There is, however, some code for explicitly whapping processes using
the old job control stuff upside the head - the comment says it's there
to catch those programs.  I don't know whether it would have been possible,
or desirable (given the goals they had), to do a backward compatible
interface or not.  You can achieve the same effect using the new signal
mechanism.

3) There is a 4.1 compatibility library built, but there is also a System V
compatibility library built - or, at least, that's what I infer from the
directory name.  It includes "tmpnam()" and the routines "strcatn", "strcpyn",
etc. - but the "strcatn" routines, etc. were old old old routines which
were renamed "strncat", etc. as the result of a big "let's standardize the
names of the string routines" (and "let's make them unique in the first six
letters so as not to upset 370s running MVS and the like") push in Bell
Labs (check out the "C environment" documents that come with System III
for this).  Were they stuck in so that programs from Bell which still hadn't
converted would run?  I find no trace of those routines anywhere in the
"libc" source for System V - so 4.2's "S5 compatibility library" is backward
compatible with a release of UNIX (UNIX/TS 1.0?) that System V itself isn't
backward compatible with any more!  Also, why was "tmpnam" stuck in but
no others?

Berkeley wanted people to use the new signal stuff (i.e., the stuff in -ljobs)
because it did solve some nasty problems with V6/V7/S3/S5/... signals (the
window of vulnerability :-) between getting a signal and resetting it, lost
information when a system call was interrupted, etc.) but the new new signal
stuff is intended to do the same.  Furthermore, if you had a program using
the new signal stuff on 4.1 "read", "write", and "wait" got restarted on
interrupts just like on 4.2, so you had to be a bit careful there (although,
admittedly, if you didn't link it with -ljobs you got the V6/V7/S3/S5/...
behavior).  Perhaps there should have been a compatibility library for
old programs, so that if you didn't do anything special you got the new
signal stuff but you could ask for the old stuff if you wanted.

I think the new signal facility is a major improvement (i.e., it means that
signals can be used more reliably, although with the availability of general,
efficient, and reliable IPC the need for them will hopefully diminish), but
perhaps a little more attention should have been paid to backwards
compatibility for the benefit of people moving large systems to 4.2 who
can't afford to immediately plunge in and convert their signal-handling
code - all that would have been necessary would have been to put in a
compatibility library with a "signal()" which calls the backward-compatible
system call and perhaps a "-ljobs" for backwards compatibility.

If, f'rinstance, Ma Bell went to that signal mechanism (they contemplated
putting a signal mechanism like the 4.1 mechanism at one point, or at least
one project did), they'd have to leave some backward compatibility hooks in
because I'd be willing to bet there are a lot of telco applications (PDP-11s
and VAXes supporting telco operations) which depend on the old-style
interrupted system call behavior.  Ultimately, they should cut over to the
new style, but a grace period might have been nice.  On the other hand, I'll
bet other operating systems have had the same type of problems when converting
from release N to release N+1...

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