Re: [RFC] Toward Shareable POSIX Signals

[Florian Weimer <fweimer at redhat dot com>]

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.  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.

> 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.

> > 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.

> > 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.

Thanks,
Florian