[RFC] Toward Shareable POSIX Signals

[dancol@dancol.org]

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

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.

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

> 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. I don't think standardizing on
a single event loop is realistic considering that various event loop
libraries have been around for many years and not achieved any kind of
fixation.