Re: [RFC] Toward Shareable POSIX Signals

[Rich Felker <dalias at libc dot org>]

On Fri, Mar 09, 2018 at 05:58:51PM +0100, Florian Weimer wrote:
> On 03/09/2018 05:41 PM, Rich Felker wrote:
> >"Just use glib" is of course fundamentally unacceptable. But the
> >obvious solution is "just use threads" and I don't see why that's not
> >acceptable. The cost of a thread is miniscule compared to the cost of
> >a child process, and threads performing synchronous waitpid can
> >convert the result into whatever type of notification (poll wakeup,
> >cond var, synchronous handling, etc.) you like. This is clearly the
> >best approach for any application that's not creating at least
> >tens/hundreds of child processes per second; when people refuse to use
> >it in such a situation, it's because of irrational aversion to threads
> >and nothing else.
> 
> But this only works for asynchronous signals.  It's reasonable for
> an application to want to catch synchronous signals (SIGBUS when
> dealing with file mappings, SIGFPE for arithmetic), and there is
> currently no thread-safe or library-safe way at all to do that.

Yes, as I noted each use case needs to be considered separately to
determine if there's some other better/more-portable/whatnot way it
could be done already. The above applies only to SIGCHLD.

FWIW I'm rather skeptical of many of the usage cases for synchronous
signals (most are dangerous papering-over of UB for dubious
performance reasons; never-taken "test reg,reg;jz" takes essentially 0
cycles on a modern uarch) but SIGBUS makes it hard to use mmap safely
to begin with. So there's still a lot of material to consider here.

FYI Daniel proposed the ideas to me first before posting on libc-alpha
and I suggested bringing a proposal here. I'm rather split between
finding the proposal nice and finding signals irredeemably awful.

Rich