xsimon@its63b.UUCP (05/27/87)
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"
edw@ius2.cs.cmu.edu (Eddie Wyatt) (05/28/87)
You have a lot to learn. One, do you know about the system calls signal and sigvec? As soon as you set up a handler then SIGUSR1 and SIGUSR2, they have real meaning and usefulness. I'm not going to go into all the things you can do. Two, there are sychronous and asynchronous messages passing conventions. What do you think the SIGURG is used for. There are limitations like the number of bytes you may send out of band (asychronously) and you must do a few strange things to enable interrupts to be generated on the socket but the facility exist, at least in Berkley Unix. -- Eddie Wyatt e-mail: edw@ius2.cs.cmu.edu
guy@gorodish.UUCP (05/28/87)
> It would seem that System V's "user definable" signals SIGUSR1 and SIGUSR2 And 4.3BSD's... > 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 > 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). Nope. Two processes can be running programs that agree on the meaning of SIGUSR1 or SIGUSR2. (No, the fact that one of those processes might do an "exec" isn't relevant - if they agree on the meaning of one of these signals, they should also agree not to "exec" any programs that don't also agree.) However, there is a problem with them that renders them dangerous to use on S5RN for N < 3; they're signals, which means that there is a window between the arrival of the signal and the call to "signal" inside the handler to set the action to SIG_IGN where the arrival of another such signal will kill the process. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
wagner@iaoobelix.UUCP (05/30/87)
I really cannot agree to that. SIGUSR[12] might be useful for special
operations triggered by sending one of these signals to a process. Using
SIGUSR[12] guarantees that the signal is not caught eventually by any
system-defined handler you haven't been aware of. E.g. I am using the SIGUSR1
signal to start a screen refresh operation of my `suntools' process...
Juergen Wagner, (USENET) ...seismo!unido!iaoobel!wagner
("Gandalf") Fraunhofer Institute IAO, Stuttgartxsimon@its63b.ed.ac.uk (Simon Brown) (06/04/87)
In article <1179@ius2.cs.cmu.edu> edw@ius2.cs.cmu.edu (Eddie Wyatt) writes: > >One, do you know about the system calls >signal and sigvec? As soon as you set up a handler then SIGUSR1 and >SIGUSR2, they have real meaning and usefulness. I'm not going to go into >all the things you can do. I think you have missed the entire point of what I was trying to say. Sure, you can trap SIGUSR[12], but using them is dangerous and restrictive because: a) They are "global" (like all signals), so there can be no guarantee that some bastard process won't send them to a process that is making some special use of them. This is reasonable for signals which have a well-defined meaning, but not for these. b) Some not-very-vanilla System-V's have BSD sockets bolted on, with "#define SIGURG SIGUSR1" in <signal.h>. However, BSD's SIGURG is ignored if set to SIG_DFL, whereas this fake nasty SysV SIGURG (USR1) causes termination. This can be very embarassing in a process which has a socket open unknown to it (inherited from its parent) - it doesn't know it's got a socket open and so is in danger of getting a SIGURG, so it probably won't bother to trap SIGURG (ie, SIGUSR1). Of course, this isn't a very meaningful objection, since I shouldn't be using such a cruddy system in the first place, I suppose :-) c) There are only two of them, which isn't enough. > > Two, there are sychronous and asynchronous messages passing conventions. >What do you think the SIGURG is used for. There are limitations like the >number of bytes you may send out of band (asychronously) and you must do a >few strange things to enable interrupts to be generated on the socket but >the facility exist, at least in Berkley Unix. > I was talking 'bout System V, really, and the msgop IPC. But yes, I suppose SIGURG does the job for the Berkeley heap. > Eddie Wyatt >e-mail: edw@ius2.cs.cmu.edu -- ---------------------------------- | 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"
rml@hpfcdc.UUCP (06/09/87)
> I think you have missed the entire point of what I was trying to say. Sure, > you can trap SIGUSR[12], but using them is dangerous and restrictive because: > a) They are "global" (like all signals), so there can be no > guarantee that some bastard process won't send them to a > process that is making some special use of them. This is > reasonable for signals which have a well-defined meaning, but > not for these. I don't understand why this is more reasonable for signals "with a well-defined meaning." If a program catches SIGALRM expecting it to indicate expiration of a timer and some "bastard process" sends it a SIGALRM, the program does the wrong thing. This doesn't seem very different from the situation with SIGUSR1. Besides, the program that doesn't catch SIGUSR1 and dies from the stray signal is probably no better off than the one that catches and misinterprets it. The point is that there should not be "bastard programs" floating around sending any unexpected potentially fatal signals to unsuspecting programs. Since the ability to send a signal is restricted by user ID, it seems you have only yourself or your system administrator to blame if they do exist. > b) Some not-very-vanilla System-V's have BSD sockets bolted on, with > "#define SIGURG SIGUSR1" in <signal.h>. This is indeed misuse of a "user-defined" signal. The IEEE 1003.1 standard is attempting to clarify this more by describing these signals as "reserved as application defined signal". > c) There are only two of them, which isn't enough. This is a limitation, but it doesn't quite make the feature useless. Bob Lenk {ihnp4, hplabs}!hpfcla!rml