Re: [RFC] Toward Shareable POSIX Signals

[Ondřej Bílka <neleai at seznam dot cz>]

On Thu, Mar 08, 2018 at 01:50:17PM -0800, dancol@dancol.org wrote:
> > 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.
>
Reality is that people don't bother and use first code that appears to
work. 

So aim is to make these as safe as possible by default.
 
> >> > 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.)
> 
Florian and I were talking about async signals and that they should be
handled in single event loop to serialize them. That there may be other
event loops is irrelevant. 


> > 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.
>
This starts with

> > Async signals 

So sync part isn't relevant. Beside that you could do sync signals using
different thread if you don't care about overhead. Kernel could create
lock for offending thread/process, signal handler would run in different thread
which would unlock to resume offending thread when condition was handled. 

This isn't done because creating thread contexts just to handle signals
in single thread application is too expensive.