On Sun, Jul 1, 2018 at 9:47 AM Joerg Sonnenberger <[email protected]> wrote:
> On Fri, Jun 29, 2018 at 04:21:17PM +0200, Alexander Bluhm wrote:
> > The problem is that POSIX has signals that are sent to processes
> > and signals sent to individual threads. Our kernel does not support
> > this properly.
>
> Well, not exactly. POSIX has synchronous and asynchronous signals. I.e.
> SIGFPE after a division by zero or SIGBUS/SIGSEGV are typically
> synchronous traps thrown by the processing of the instructions of the
> current thread. This signals are delivered to the current thread. All
> other signals, i.e. those created as side effect of kill(2) are sent to
> the process at large.
I think Bluhm's wording is more true to POSIX, as there are other methods
for a signal to be delivered to a specific thread. To quote POSIX XSH
2.4.1p2:
At the time of generation, a determination shall be made whether the
signal
has been generated for the process or for a specific thread within the
process.
Signals which are generated by some action attributable to a particular
thread,
such as a hardware fault, shall be generated for the thread that caused
the
signal to be generated. Signals that are generated in association with
a process
ID or process group ID or an asynchronous event, such as terminal
activity,
shall be generated for the process.
Later, it specifies that pthread_kill() generates the signal for the
specific thread:
The pthread_kill() function shall request that a signal be delivered to
the specified thread.
Those signals are handled by the first thread that
> doesn't have them masked. In that case, it should be put on the pending
> list of the process and any unmasking operation should check the pending
> list on whether a signal should be delivered delayed.
>
Yep.
Philip Guenther
