Re: [RFC] Toward Shareable POSIX Signals

[dancol@dancol.org]

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

Writing a robust handler requires some understanding of the subtleties
involved, but it's in no way impossible or even particularly difficult.
It's the moral equivalent of writing the top half of an interrupt handler.
People do that all the time.

Besides: people are _already_ using signals for this purpose. Practically
every high-performance language runtime already hooks various signal
handlers, and for good reason. There's no reason it should be hard for
these systems to coexist in the same process, and something like glib does
nothing to help sharing.

I'm proposing making existing use cases more portable and more robust.

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

Nobody will agree on a single event loop library. There is, for example,
_zero_ chance that popular mobile operating systems will adopt glib as the
primary event dispatching mechanism. In any case, an event loop doesn't
help with the synchronous signal sharing use cases --- the ones, for
example, a SIGSEGV-using high-performance runtime might require. (See the
first of my use cases on my original post.)

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


It's not performance. It's that certain events, particularly those related
to memory errors, _need_ to be addressed immediately and synchronously.
Even if you were to use something like the Mach ports mechanism and send a
message instead of pushing a stack frame, you'd still have to
synchronously block a faulting thread, which could be anywhere, thus
giving you the same atomicity constraints.