[RFC] Toward Shareable POSIX Signals

[Ondřej Bílka]

On Thu, Mar 08, 2018 at 12:22:05PM -0800, dancol@dancol.org wrote:
> > 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?
>
Basic problem is that if you combine signals, threads and locks you get
a big mess. 

It is hard to write handler doing something complex, you
couldn't take any lock because thread you interrupted could have that
lock. Introducing signal leads to unexpected race conditions(for example
what happens when interrupt is interrupted?).

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

Original answer to use event loop, doesn't matter which one. 

Async signals should be handled as separate thread which has event loop
to serially handle arrived signals. That would remove most difficulties
of signal handlers.

Reason why this isn't default is performance and putting this to another
event loop is compromise.