Re: [RFC] Toward Shareable POSIX Signals

[Daniel Colascione <dancol at dancol dot org>]

On 03/09/2018 09:14 AM, Rich Felker wrote:
> 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 

They work fine. Billions of people every day use devices with a runtime 
that safely uses a SIGSEGV optimizations. It's hard to make the case 
that this technique doesn't actually work or is somehow dangerous.

> papering-over

It's not "papering-over". It's intended design: don't make the common 
case pay for the uncommon case.

> of UB 

It's not UB at the level we're talking about. Of course just longjmping 
from random code that segfaults is likely a bad idea. (I'm looking at 
you, Emacs stack recovery code.) But if you know what you're doing and 
can constrain the situations in which you do non-local control flow in 
response to a SIGSEGV, you can create something that's perfectly safe 
and efficient.

> for dubious
s/dubious/important/

> performance reasons; never-taken "test reg,reg;jz" takes essentially 0
> cycles on a modern uarch) 

It isn't.

> but SIGBUS makes it hard to use mmap safely
> to begin with. So there's still a lot of material to consider here.

Right. It's reasonable to want to transform SIGBUS into some kind of 
friendly high-level error, and to do that, you need a SIGBUS handler. 
It's reasonable for multiple such systems in a single process to want to 
convert their respective SIGBUS errors into friendly errors, so we need 
some way to share the SIGBUS signal.