The entry in POSIX on "Signal Generation and Delivery" in "Rationale: System Interfaces General Information" says
Signals generated for a process are delivered to only one thread. Thus, if more than one thread is eligible to receive a signal, one has to be chosen. The choice of threads is left entirely up to the implementation both to allow the widest possible range of conforming implementations and to give implementations the freedom to deliver the signal to the "easiest possible" thread should there be differences in ease of delivery between different threads.
signal(7) manual on a Linux system:
A signal may be generated (and thus pending) for a process as a whole
(e.g., when sent using
kill(2)) or for a specific thread (e.g., certain
signals, such as SIGSEGV and SIGFPE, generated as a consequence of executing a specific machine-language instruction are thread directed, as are
signals targeted at a specific thread using
pthread_kill(3)). A process-directed signal may be delivered to any one of the threads that does not
currently have the signal blocked. If more than one of the threads has the
signal unblocked, then the kernel chooses an arbitrary thread to which to
deliver the signal.
Threads have distinct alternate signal stack settings. However, a new
thread's alternate signal stack settings are copied from the thread that
created it, so that the threads initially share an alternate signal
stack (fixed in kernel 2.6.16).
pthreads(3) manual on an OpenBSD system (as an example of an alternate approach):
Signals handlers are normally run on the stack of the currently executing
(I'm currently not aware of how this is handled when multiple threads are executing concurrently on a multi-processor machine)
The older LinuxThread implementation of POSIX threads only allowed distinct single threads to be targeted by signals. From
pthreads(7) on a Linux system:
LinuxThreads does not support the notion of
process-directed signals: signals may be sent only to specific threads.