4.2 signals broken?

Bill Shannon shannon at sun.uucp
Thu Dec 8 19:23:47 AEST 1983


Clyde Hoover says,
	"I am also upset at the dissapearance of sigset, sighold,
	sigrelse and all the other special signal setting routines
	we were told to use in our VAX code by the Berkeley boys."

Who told you to use that stuff?

In the DESCRIPTION section of sigset(3) in the 4.1bsd manual it says,
	"These functions are only available in this version of UNIX,
	and should not be used when the mechanisms of signal(2) would
	suffice, as they would then impair portability."

In the BUGS section of sigsys(2j) in the 4.1bsd manual it says,
	"These facilities are still under development and may change
	in future releases of the system....  The options and
	specifications of this facility and the system calls supporting
	it are thus subject to change."

Don't say you weren't warned.

And yes, if you want to write portable code you won't use any of the
new 4.2bsd signal facilities and you won't depend on either the V7 or
the 4.2 signal handling (in terms of interrupting system calls).  If
you use setjmp/longjmp to try to get around some of these problems in
a portable manner you also have to be careful of some of the problems
of setjmp/longjmp.  On many machines, when you do a longjmp all register
variables will be reset to the values they had at the time you did the
setjmp, whereas all non-register variables will have the same values
they had at the time you did the longjmp.  This can cause some very
bizarre bugs.

I agree that there is no excuse for not providing a backwards compatible
signal interface.  And while we're at it, how many of you depend on the
signal handler getting reset to SIG_DFL when you catch a signal?  That
was "fixed" in 4.2 and would have to be "unfixed" to provide a backwards
compatible signal interface.

					Bill Shannon
					Sun Microsystems, Inc.



More information about the Comp.unix.wizards mailing list