signalfd and thread semantics

signalfd and thread semantics

[Michael Kerrisk]

Hi Davide,

Working on the signalfd man page, another question comes up:

What are the intended semantics for a signalfd file descriptor with respect
to threads?  I have not yet tested the behavior, but in any case, I better
check what is expected.

A signal can be directed to the process as a whole (e.g., using kill(2)),
or to a particular thread (using, e.g., pthread_kill(2), or tgkill(2)).

So that raises the question: If a thread calls signalfd(), does the
resulting file descriptor return just those signals directed to [the thread
and the process as a whole], or will it also receive signals that are
targeted at other threads in the process?  I would hope the former is the
case, but I'm not sure what has been implemented (or intended).

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7

Want to help with man page maintenance?  Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages/
read the HOWTOHELP file and grep the source files for 'FIXME'.

Re: signalfd and thread semantics

[Davide Libenzi]

On Tue, 17 Jul 2007, Michael Kerrisk wrote:

> Hi Davide,
> 
> Working on the signalfd man page, another question comes up:
> 
> What are the intended semantics for a signalfd file descriptor with respect
> to threads?  I have not yet tested the behavior, but in any case, I better
> check what is expected.
> 
> A signal can be directed to the process as a whole (e.g., using kill(2)),
> or to a particular thread (using, e.g., pthread_kill(2), or tgkill(2)).
> 
> So that raises the question: If a thread calls signalfd(), does the
> resulting file descriptor return just those signals directed to [the thread
> and the process as a whole], or will it also receive signals that are
> targeted at other threads in the process?  I would hope the former is the
> case, but I'm not sure what has been implemented (or intended).

If thread A calls signalfd(), a read() from the signalfd will return 
thread A private (tgkill) signals (only when called by thread A) and 
thread A shared (kill) signals (readable from any thread).
So a call to signalfd() virtually attaches the fd to the calling thread 
signal context.
This is the reason of the "virtual connection" dropped I was talking about 
in the other email. If the signal context the fd is attached to 
(struct sighand), goes away, the fd becomes like a disconnected socket 
with no peer to read form.



- Davide

Re: signalfd and thread semantics

[Michael Kerrisk]

> On Tue, 17 Jul 2007, Michael Kerrisk wrote:
> 
> > Hi Davide,
> > 
> > Working on the signalfd man page, another question comes up:
> > 
> > What are the intended semantics for a signalfd file descriptor with
> > respect to threads?  I have not yet tested the behavior, but in 
> > any case, I better check what is expected.
> > 
> > A signal can be directed to the process as a whole (e.g., using
> > kill(2)), or to a particular thread (using, e.g., pthread_kill(2), 
> > or tgkill(2)).
> > 
> > So that raises the question: If a thread calls signalfd(), does the
> > resulting file descriptor return just those signals directed to [the
> > thread and the process as a whole], or will it also receive signals 
> > that are targeted at other threads in the process?  I would hope the 
> > former is the case, but I'm not sure what has been implemented 
> > (or intended).
> 
> If thread A calls signalfd(), a read() from the signalfd will return 
> thread A private (tgkill) signals (only when called by thread A) and 
> thread A shared (kill) signals (readable from any thread).
> So a call to signalfd() virtually attaches the fd to the calling thread 
> signal context.
> This is the reason of the "virtual connection" dropped I was talking 
> about in the other email. If the signal context the fd is attached to 
> (struct sighand), goes away, the fd becomes like a disconnected socket 
> with no peer to read form.

It's late at night, and perhaps I am being slow: in what 
circumstances can the signal context go away while the
thread itself continues to live?  (I mean in
what circumstances from the point of view of the userland
program?)

Cheers,

Michael
-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages , 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.