svn commit: r209595 - head/sys/kern
John Baldwin
jhb at freebsd.org
Wed Jun 30 16:05:31 UTC 2010
On Wednesday 30 June 2010 9:59:34 am Matthew Jacob wrote:
> Excuse my ignorance, but aren't signals supposed to be to processes, not
> specific threads?
Not for synchronous events. For example, when you get a segfault due to a
NULL pointer the SIGSEGV is sent to the thread that actually segfaulted, not
any random thread in the process. Similarly for floating-point exceptions,
etc. POSIX also mandates this for SIGPIPE as you can see from this
description of 'EPIPE' from write(2) and fflush(3):
[EPIPE]
An attempt is made to write to a pipe or FIFO that is not open for
reading by any process, or that only has one end open. A SIGPIPE signal
shall also be sent to the thread.
(Note thread, not process, in other places the language uses process, but it
specifically uses thread here.)
> My memory/knowledge of Posix in this area is very rusty.
>
> > On Tuesday 29 June 2010 5:05:22 pm Ed Schouten wrote:
> >
> >> * John Baldwin<jhb at FreeBSD.org> wrote:
> >>
> >>> Log:
> >>> Send SIGPIPE to the thread that issued the offending system call
> >>> rather than to the entire process.
> >>>
> >> Should something similar be used inside the TTY layer, where
> >> reads/writes may cause signals to be generated?
> >>
> > Hmm, I'm not sure. I do think you want to stop the entire process for SIGTTOU
> > or SIGTTIN (often the entire process group it seems), so I'm not sure if it
> > matters if the signal is sent to only the current thread versus sending it to
> > any thread in the process.
> >
> >
>
>
--
John Baldwin
More information about the svn-src-head
mailing list