Re: signalfd API issues (was Re: [PATCH/RFC] signal races/bugs, losing TIF_SIGPENDING and other woes)

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 5 Jun 2007, Davide Libenzi wrote:
> On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> > 
> > Yeah, synchronous signals should probably never be delivered to another
> > process, even via signalfd. There's no point delivering a SEGV to
> > somebody else :-)
> 
> That'd be a limitation. Like you can choose to not handle SEGV, you can 
> choose to have a signalfd listening to it. Of course, not with the 
> intention to *handle* the signal, but with a notification intent.

I agree that it would be a limitation, but it would be a sane one.

How about we try to live with that limitation, if only to avoid the issue 
of having the private signals being stolen by anybody else. If we actually 
find a real-live use-case where that is bad in the future, we can re-visit 
the issue - it's always easier to _expand_ semantics later than it is to 
restrict them, so I think this thread is a good argument for starting it 
out in a more restricted form before people start depending on semantics 
that can be nasty..

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