Quote:
Originally Posted by
Tru69
Do signals actually produce interrupts (traps) to the signaled processes so they immediately see them?
You seem to intuitively underlay your picture of how things work with the x86 architecture. While this is a very wide-spread platform there are very different designs on which UNIX/UNIX-like systems runs with the same ease as on Intel platforms.
A process signal is no interrupt at all, these are two different things.
An "interrupt" is something (in fact a signal) to the processor, usually issued by an "interrupt controller". It makes the processor get out of its current queue, enter another queue and - after finishing it - either return into the old queue or not.
A "signal" (in the sense of UNIX process signals, like SIGINT, etc.) are merely raised flags in the process accounting/scheduling part of the kernel.
To explain on your own example: when a user presses "CTL-C", a keyboard interrupt is issued, because UNIX, as a midrange system, runs usually on interrupt-driven systems (although not necessarily, like z/Linux, which runs on systems not entirely interrupt-driven, aka IBM mainframes). With PCs this is a BIOS interrupt (09 - keyboard), which will be passed to the keyboard driver. This driver will make sense of all the various make- and break-codes issued by the [8602- or similar]-microcontroller and figure out that the user pressed CTL-C (i am following the Intel-architecture here as it seems to be the one you are most familiar with, other systems might work differently but the principle remains the same). The kernel, learning about the user pressed CTL-C raises some flags in its process scheduling/job control part and the next time the process is passed a CPU the process will "know" that a SIGINT signal was sent. Now the process can decide if to handle it or ignore it.
I hope this helps.
bakunin
