| loic-dev@gmx.net 2006-10-16, 7:32 am |
| Hello,
> Correct me where I'm wrong.
yes, you're wrong.
> When a signal is sent to the computer the CPU switches to kernel mode.
> The signal # is then looked up in a table that holds the signal #'s and
> their associated catch code address. Is there a name for this table?
> Is there a table like this for every running process on a UNIX system?
> Control is sent to the catch code. The CPU stays in kernel mode during
> the execution of this code so kernel commands that are placed in the
> catch code by the programs author could be executed. What types of
> kernel commands (if any) could be executed in this code? The signal
> catch code is completed and an address is popped off the stack that
> points to the section of code the program was at when the interrupt was
> received. CPU is switched to user mode and control is returned to the
> place where the interrupt was received.
>
> If you know any further details on this topic I would be interested to
> read those as well.
There are two sources for signal: signal generated by the hardware
(like hardware faults, timer expiration...) and signal generated by
software (using the /kill()/ system call ). In the first case, the
kernel shall map the hardware exception into a well know UNIX signal
(one in the list shown by kill -l). That's perhaps the mapping you are
referring (but it is unlikely implemented with a lookup table).
Once the kernel receives the signal, it delivers it to the target
process. The signal is nothing but a bit mask (on Linux for instance,
it is 64 bits long) contained in the process structure. Sending a
signal means nothing but changing that bit mask to reflect the signal's
number delivered. E.g. if bit 11 is set, it means that signal 11 ==
SIGSEGV has been send (things in a bit more complicated for realtime
signals, has they must be queued. But let's ignore them for our
discussion).
If the signal is not blocked by the process, and a process has defined
a signal handler, then the kernel switches back from kernel to user
space, and executes that handler. IOW, the signal handler runs in user
space. If the handler returns, a switch is done from user space to
kernel space. At that point, after some bookkeeping actions, the kernel
switches back from kernel to user space, and the process execution is
resumed where it has been interrupted.
Some interesting information about signal mechanism under Linux can be
found at:
http://www.linuxjournal.com/article/3985
HTH,
Loic.
|