Re: [RFC] Toward Shareable POSIX Signals

[Zack Weinberg <zackw at panix dot com>]

On Fri, Mar 9, 2018 at 11:41 AM, Rich Felker <dalias@libc.org> wrote:
> 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?

This is a good question to ask.

I tend to think that the basic mechanism of signals -- interrupting
normal user-space execution and transferring control to a handler
function -- is irretrievably flawed; not even as a design, but as a
_concept_.  This should not be a thing that ever happens to user
space.  As such, I appreciate Daniel's having taken the time to
canvass existing use cases for signals that are poorly served, or not
served at all, by any alternative, but I'm not a fan of any of his
proposed solutions.  I would like to work toward an end-state of
being able to remove <signal.h> from ISO C and POSIX.

[Daniel:]
>> 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).)

pdfork / forkfd is obviously the correct replacement for SIGCHLD, and
it's infuriating that it still hasn't gotten traction.  pdfork is
still (documented as) incomplete as of FreeBSD 11, and the CLONE_FD
patches for Linux don't seem to have gone anywhere since 2015.  I'd
want to see a few refinements, notably an fcntl or ioctl that's
equivalent to WUNTRACED (that is, it controls whether select() will
wake you up when the process _stops_; without that, shells can't
really use pdfork) but if you (Daniel) were to pick up the pdfork ball
and get it accepted on the other *BSDs and on Linux, you'd have made
significant progress in this area.

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

The main problem I see with this idea is, a thread waiting for _any_
process can steal the event from a thread waiting for a specific
process; this makes it nonviable for any situation where you don't
control all of the code in the parent process.  In particular, this is
not a viable solution for libraries that want to run helper programs.
It is unclear to me whether pdfork-as-implemented (in FreeBSD 11) has
this problem; the manpage says that a pdfork'ed child does not fire
SIGCHLD, but it doesn't say whether an ordinary waitpid for the
process ID, or wait-for-any, can compete with pdwait4 on the fd
(perhaps because "pdwait4 has not yet been implemented", sigh...)

...
> On Fri, Mar 09, 2018 at 05:58:51PM +0100, Florian Weimer wrote:
>> But [threads] only works for asynchronous signals.  It's reasonable
>> for an application to want to catch synchronous signals (SIGBUS
>> when dealing with file mappings, SIGFPE for arithmetic), and there
>> is currently no thread-safe or library-safe way at all to do that.
>
> Yes, as I noted each use case needs to be considered separately to
> determine if there's some other better/more-portable/whatnot way it
> could be done already. The above applies only to SIGCHLD.
>
> FWIW I'm rather skeptical of many of the usage cases for synchronous
> signals (most are dangerous papering-over of UB for dubious
> performance reasons; never-taken "test reg,reg;jz" takes essentially 0
> cycles on a modern uarch) but SIGBUS makes it hard to use mmap safely
> to begin with. So there's still a lot of material to consider here.

If I remember correctly, GCJ tried to use signal handlers to generate
NullPointerExceptions not for speed reasons, but for code-size and
exception-precision reasons.  But it was never 100% reliable and it
might have been better to go with "test reg,reg;jz" + lean harder on
proving pointers couldn't be null.

That's the only case I'm personally familiar with where a serious
application tried to _recover from_ synchronous signals.  I've also
dug into Breakpad a little, but that is a debugger at heart, and it
would be well-served by a mechanism where the kernel would
automatically spawn a ptrace supervisor instead of delivering a fatal
signal.  (This would also allow us to kick core dump generation out of
the kernel.)

> FYI Daniel proposed the ideas to me first before posting on libc-alpha
> and I suggested bringing a proposal here. I'm rather split between
> finding the proposal nice and finding signals irredeemably awful.

Yeah, I feel we collectively could have done a better job of not
leaping at Daniel's throat just for bringing this up.

zw