Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcvax!ukc!its63b!xsimon
From: xsimon@its63b.UUCP
Newsgroups: comp.unix.questions
Subject: SIGUSR1, SIGUSR2 are pretty useless
Message-ID: <444@its63b.ed.ac.uk>
Date: Wed, 27-May-87 12:25:46 EDT
Article-I.D.: its63b.444
Posted: Wed May 27 12:25:46 1987
Date-Received: Fri, 29-May-87 05:06:49 EDT
Reply-To: xsimon@its63b.ed.ac.uk (Simon Brown)
Organization: Computer Science Department, Edinburgh University
Lines: 41

It would seem that System V's "user definable" signals SIGUSR1 and SIGUSR2
are really not so useful after all. A signal may only be safely sent to a
process if its "meaning" in the target process can be guarenteed. (eg, if
you send SIGHUP, it had *better* interpret that as a hangup!).
However, SIGUSR[12] have no such fixed purpose, so the only way it is
completely safe to use these is for a process to kill itself (or possibly
its children or its parent, if it can be sure they're executing from the
same image - havn't done an exec).

What is really needed is something along the same lines as the IPC calls
(msgop, shmop, semop, etc...), which can dynamically allocate unique new
descriptors for general use by anyone (and remove them when they're done).
So, something like
	int sigget(key, sigflags)
	key_t key;
	int sigflags;
would allocate a signal identifier, based on the given key. Signal trapping
could then use these identifiers in place of the current constant values
(SIGHUP, SIGINT, etc...). The real plus is that an IPC_PRIVATE key would
produce a "new" signal, just for use by that process and its descendents,
without fear of using up a signal that is being used for some other hidden
purpose by someone else which might conceivably disable your own use of it
(eg, some people use SIGUSR1 and SIGUSR2 for all sorts of bad things -
like to trigger screen-redrawing with system V sxt job control, or as
BSD-socket signals for people with cheap-grotty-plastic sockets squeezed
into their sysV system).

Of course, what is *really* needed is a new form of msgops that supports
both synchronous and asynchronous messages, then signals could go away :-)

[Disclaimer: It's Wednesday.]

*=Simon

-- 
----------------------------------
| Simon Brown 		         | UUCP:  seismo!mcvax!ukc!{its63b,cstvax}!simon
| Department of Computer Science | JANET: simon@uk.ac.ed.{its63b,cstvax}
| University of Edinburgh,       | ARPA:  simon%{its63b,cstvax}.ed.ac.uk ...
| Scotland, UK.			 |				@cs.ucl.ac.uk
----------------------------------	 "Life's like that, you know"