>
> > > > 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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-