I have been reading Vahalia's Unix Internals book, which states the following in the chapter dedicated to signals:
Given that, my understanding is that processes running in user mode don't become aware of signals until they switch to kernel mode, where the issig() function is called at some points.
However, he later gives an example where a user would type ctrl+c at a terminal, sending a SIGINT signal to the foreground process. If it happens that this process is running on another CPU, a special "cross-processor" interrupt is needed so that the target sees the signal. But why is that? Do signals actually produce interrupts (traps) to the signaled processes so they immediately see them? Otherwise, wouldn't it be enough to just set a flag in this process' structure, which would be then checked in one of that three situations described before?
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.
Raising flags in a process structure was the idea I had about signal posting. It is this "cross-processor interrupt" thing what made me doubt. I've been looking for information about this, and it seems to be Solaris related. This is a quote from the Solaris Internals book:
However, I still don't know why such a signal delivery requires interrupting the processor the process is running in. Why can't those flags be simply raised for this process?
These flags don't just sit there, they tell the kernel what to do. Setting one may mean the kernel has to take some action to accomplish what it's supposed to do.
This discussion is now crossing three different meanings of 'interrupt', by the by.