Re: [RFC] Toward Shareable POSIX Signals

[Daniel Colascione <dancol at dancol dot org>]

On 03/09/2018 01:19 AM, Florian Weimer wrote:
> On 03/08/2018 09:22 PM, dancol@dancol.org wrote:
> > > On 03/08/2018 06:52 PM, Daniel Colascione wrote:
> > > > Windows Vectored Exception Handlers
> > > > -----------------------------------
> > > >
> > > > Windows isn’t a POSIX system and doesn’t have signals per se, 
> > > > but it
> > > > does have a similar concept of a global unhandled “exception” 
> > > > (e.g.,
> > > > SIGSEGV-equivalent) handler. Vectored Exception Handlers allow
> > > > multiple components to cooperate in handling these exceptions and
> > > > operate very similarly to the mechanism that this document proposes.
> > >
> > > For many of the things you listed (particularly the synchronously
> > > delivered signals), Structured Exception Handling (SEH) would actually
> > > be the proper model (with a table-driven implementation).  It would
> > > allow to install handlers for small regions of code, which helps with
> > > modularity, and the handlers would be effectively thread-local.
> >
> > Not the case. SEH works only when you know about all the call sites that
> > might generate an exception. Sometimes, you want generic process-wide
> > handling keyed on memory address.
>
> There is userfaultfd for that.  

userfaultfd is an optional kernel feature, not a standard interface, and 
it's never realistically never going to be adopted on non-Linux systems.

> However, I find it a bit scary to paper 
> over segmentation faults for unknown call sites.  This seems to be a bit 
> of a fringe application, also considering that page faults keep getting 
> more and more expensive.

People use signals for lots of things today. They mostly work fine. I'm 
proposing a mechanism to make signals *less* "scary", not *more*. 
Besides, it's not libc's job to make value judgments about which 
techniques application developers should use. At this low level, 
libraries should provide capabilities, not opinions.

> > We don't have SEH, however, and there's no realistic prospect of getting
> > it. It would be realistic to extend the signals API to support more use
> > cases.
>
> At present, we don't have those stacked signal handlers, either.  I'm 
> just saying that there is a better model for synchronous signals.

The two models work together. But since we don't have SEH and will 
realistically never have it (especially if this "signals are scary" 
attitude persists), sharing the existing signal handler mechanism is better.

> > > For asynchronously delivered signals (such as subprocess termination),
> > > the signal mechanism may not be entirely appropriate anyway.
> >
> > It beats wait. Which part of my proposed mechanism would operate 
> > improperly?
>
> It just doesn't scale at all.  For each subprocess termination, you have 
> to iterate through about half of the registered signal handlers until 
> you hit one that happens to know about the PID that was terminated. Same 
> for the other signals.

It's linear in the number of components asking for notification, not in 
the number of processes awaited. si_pid in siginfo makes identifying a 
particular child fast.

Also, I don't see any realistic alternatives to the wait family of APIs 
being proposed either. (And as I explain below, "just use glib" is 
completely unacceptable as a response to a fundamental defect in the 
design of wait*(2).)

In any case, focusing on this one child-monitoring use case misses the 
point. My original message lists many different example use cases for 
shared signals, all of which we could address with a simple API. It 
would take decades for standard alternatives for each of these use cases 
to become available universally.

> > > For those,
> > > standardizing on a single event loop looks like the right solution, and
> > > glib has largely taken over there.
> >
> > The libevent and Qt people might disagree.
>
> Last time I checked, Qt used the glib event loop.

It's configurable, so you can't rely on glib integration being present.

In any case, there is zero chance that something glib sees universal 
adoption, particularly outside the Gnome part of the desktop Linux 
world. Can you imagine macOS applications having a glib main event loop? 
Android? Nginx? A sane signals API would make it possible for a single 
component written against a single API to happily coexist in any of 
these environments.

Seeing "just use glib" as response to an attempt to innovate in core 
interfaces is extremely disappointing. We could fix long-standing 
problems and make software more reliable, but instead we're talking 
about a pipe dream of some single event loop library being universally 
adopted.