[RFC] Toward Shareable POSIX Signals

[Daniel Colascione]

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.