[RFC] Toward Shareable POSIX Signals

[Rich Felker]

On Fri, Mar 09, 2018 at 02:43:06AM -0800, Daniel Colascione wrote:
> People use signals for lots of things today. They mostly work fine.
> I'm proposing a mechanism to make signals *less* "scary", not
> *more*. Besides, it's not libc's job to make value judgments about
> which techniques application developers should use. At this low
> level, libraries should provide capabilities, not opinions.

I think we need to weigh the benefits of making signals less
scary/unsafe/hideous versus the benefits of leaving them so. Yes,
people use signals today. Most of the uses are utterly unsafe and
utterly wrong. Most of them are not even justified; they're for lack
of knowing better or just cargo-culting from something they saw done
elsewhere. Do new interfaces fix existing incorrect usage and
discourage it in the future?

> >>>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.
> 
> It's linear in the number of components asking for notification, not
> in the number of processes awaited. si_pid in siginfo makes
> identifying a particular child fast.
> 
> Also, I don't see any realistic alternatives to the wait family of
> APIs being proposed either. (And as I explain below, "just use glib"
> is completely unacceptable as a response to a fundamental defect in
> the design of wait*(2).)

"Just use glib" is of course fundamentally unacceptable. But the
obvious solution is "just use threads" and I don't see why that's not
acceptable. The cost of a thread is miniscule compared to the cost of
a child process, and threads performing synchronous waitpid can
convert the result into whatever type of notification (poll wakeup,
cond var, synchronous handling, etc.) you like. This is clearly the
best approach for any application that's not creating at least
tens/hundreds of child processes per second; when people refuse to use
it in such a situation, it's because of irrational aversion to threads
and nothing else.

For loads where the cost of child process creation and termination is
the dominant factor, I'll grant that the added cost of a thread
lifecycle might not be acceptable. But there are much better
approaches like just forcing each child to inherit a pipe, and polling
those pipes to determine when the child exited, that are very light
(roughly equivalent to BSD forkfd) and much cleaner than using
signals.

> In any case, focusing on this one child-monitoring use case misses
> the point. My original message lists many different example use
> cases for shared signals, all of which we could address with a
> simple API. It would take decades for standard alternatives for each
> of these use cases to become available universally.

I don't think it misses the point when the point is to determine
whether the legitimate uses of signals establish a compelling need for
new interfaces. Each possible use needs to be evaluated one by one.

> Seeing "just use glib" as response to an attempt to innovate in core
> interfaces is extremely disappointing.

Again I agree re: "just use glib", but when it comes to core system
interfaces, the principle that "a maintainer's job is to say no"
applies more than ever. Perhaps a nicer and more precise way of saying
it is that a maintainer's job is to press for justification of need by
exhaustively searching for alternatives before turning to creation of
new interfaces as a solution.

Rich