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