Messages in this thread |  | | Date | Tue, 4 Feb 1997 15:48:21 -0500 (EST) | From | "Adam D. Bradley" <> | Subject | Re: Signals |
| |
> > > I don't know what POSIX says about this, but the included code snippet > > > clearly shows that a signal handler using a negative number is allowed > > > in the existing system. However, kill() with is negative number is NOT > > > allowed. In other words, we can't ever use the signal handler that we've > > > set up!!! > > > > > > If negative signals were allowed for user signals. We've got as many > > > as we would ever need! > > > > Sorry for my ignorance, but how difficult would it be to add new signals > > to the linux kernel? SIGUSR3, SIGUSR4 etc.. ? > > It would not be very difficult at all. The main point was that negative > signals "are supposed to be" for the use of anybody. Only positive > signals of specific kinds are specified. Now, if kill() didn't trap > negative signals, I think that they would work! > > If negative signals were allowed, the kernel would not have to "add" any > "new" ones. It only uses the "defined" ones, which are only numbers.... > and allows other non-specific handlers to be defined by persons in > user-mode.
The complication is with kernel internals:
linux/include/linux/sched.h:
struct task_struct { [snip] struct signal_struct *sig; [snip] }
struct signal_struct { int count; struct sigaction action[32]; }
This imposes a hard limit: no more than 32 signals per process. Unless we do some funky stuff when allocating signal_struct. What's more, (I think - flame me gently if I'm wrong ;-) it's a hard-index (ie, signal 9 causes action[9] etc), so if a syscall allows registering of negative signals, it's actually allowing a scribble on kernel memory...(worth looking into...)
linux/include/asm-i386: struct sigaction { __sighandler_t sa_handler; sigset_t sa_mask; unsigned long sa_flags; void (*sa_restorer)(void); };
__sighandler_t is the function pointer, sigset_t is defined as unsigned long, "at least 32 bits" (flags for 32 defined symbols), sa_flags similarly. There is no mechanism in place (that I can see) to support signals besides those numbered 0..32. Now, if sigaction included a "signal number" variable (signed int signum), and we could re-work the internals to parse over the signal_struct.action[] array, checking signal_struct.action[x].signum, then there could be an arbitrary set of 32 signals for a given process. (Of course, 0,9,etc can't be arbitrarily re-assigned, but still...) Increasing the number of signals isn't in-and-of itself difficult, but I would want to look over the POSIX spec (which signal #'s are allowable, etc) to decide how to do it _efficiently_. As it is, signal_struct takes up 512Bytes (1/2K), up it to 64 signals (1K) and multiply by 100 processes and we start to get kernel-memory concerns. Perhaps dynamically-sized signal tables?
Just my $0.02...
Adam -- He feeds on ashes; a deluded mind has led him Adam Bradley, UNCA Senior astray, and he cannot deliver himself or say, Computer Science "Is there not a lie in my right hand?" Isaiah 44:20 bradley@cs.unca.edu http://www.cs.unca.edu/~bradley <><
|  |