Re: Revised signalfd man-page

[Davide Libenzi]

On Wed, 17 Oct 2007, Michael Kerrisk wrote:

> > With the new code Linus already merged, signalfd does not attach to the 
> > sighand anymore, so the "orphaned sighand" behaviour is no more there.
> > An exec() will carry the fd over, and you will be able to use the fd in 
> > the same way you did before the exec(). If sigpending()/sigwaitinfo() will 
> > show signals available, so it should signalfd.
> 
> So I wrote:
> 
>    execve(2) semantics
>        Just  like  any  other  file  descriptor, a signalfd file
>        descriptor remains open across an  execve(2),  unless  it
>        has  been  marked  for close-on-exec (see fcntl(2)).  Any
>        signals  that  were  available  for  reading  before  the
>        execve(2)  remain  available to the newly loaded program.
>        (This is analogous to traditional signal semantics, where
>        a  blocked  signal that is pending remains pending across
>        an execve(2).)  (This is analogous to traditional  signal
>        semantics, where a blocked signal that is pending remains
>        pending across an execve(2).)
> 
> Okay?

Ok



> > It'll return the signals that would be normally returned to the thread 
> > with the standard signal delivery methods. That is, calling thread private 
> > signals, and calling thread-group shared signals.
> 
> So I wrote:
> 
>    Thread semantics
>        The semantics of signalfd file descriptors  in  a  multi-
>        threaded  program  mirror the standard semantics for sig-
>        nals.  In other words, when a thread reads  from  a  sig-
>        nalfd  file descriptor, it will read the signals that are
>        directed to the thread itself and the  signals  that  are
>        directed  to the process (i.e., the entire thread group).
>        (A thread will not be  able  to  read  signals  that  are
>        directed to other threads in the process.)
> 
> Okay?

Ok, although this looks more specific:

(A thread will not be able to read other threads private signals)



- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/