Messages in this thread |  | | Date | Tue, 4 Feb 1997 18:44:12 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: Signals |
| |
On Tue, 4 Feb 1997, Adam D. Bradley wrote:
> > > > > 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!!! > > > > [SNIP]
> > 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]; > } > [SNIP]
> 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...) True. [SNIP] True [SNIP True.
No flames here. BUT these are "implementation details". They are, for the most part, derived from the need to "mask" signals. The "System Defined" signals need to be masked and it would not be efficient to look through a list to find out what was masked. Therefore a bit-mask is used. However, the basics of what one needs is:
o Positive number? Yes, do whatever... No? do this... o Allocate and set up a pointer to the function to call when a signal is sent. o After the signal is sent, deallocate the pointer-space. o Receive signal, call handler (handler's sometimes don't return) therefore, something else has to deallocate dynamic space.
This seems to be easier than using a 64-bit word for signals and then running out, needing 128 bits, etc.
Now, I have an old version of Unix System V Release 2.0 User Reference Manual, Copyright 1983 AT&T Bell Telephone Laboratories, Inc. (<grin>) The __first__ real UNIX documentation. Under SIGNAL(2) there are only 19 defined signals! Anything outside this range is illegal. However, there is also SSIGNAL(4), the "software signals" which are all user defined and, according to the documentation, are handled within the 'C' runtime library, not the kernel. These are aparently implemented from a "master" signal, SIGUSR1, because they explicitly state that when using SSIGNAL, the function of SIGUSR1 is undefined.
So, I guess that a user signal is is "kept track of" in the 'C' library but the actual call to the kernel ends up using SIGUSR1. This kind of mechanism would be easy to implement, entirely in user space. Note that only one signal of the same type can be pending at the same time, so the 'C' function only has to keep requeueing signals after each is delivered, until all pending signals are used up.
Cheers, Dick Johnson -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard B. Johnson Project Engineer Analogic Corporation Voice : (508) 977-3000 ext. 3754 Fax : (508) 532-6097 Modem : (508) 977-6870 Ftp : ftp@boneserver.analogic.com Email : rjohnson@analogic.com, johnson@analogic.com Penguin : Linux version 2.1.23 on an i586 machine (66.15 BogoMips). Warning : It's hard to remain at the trailing edge of technology. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|  |