Rethinking race-free process signaling

With signals at least most of the problems are related to inconvenient aspects of reality (i.e., signals can arrive at any moment, and the kernel can't allocate unbounded amounts of memory for a signal queue). For the core signal use cases like SIGSEGV or SIGTERM, I don't think there's a lot of room for improvement. There are also too many APIs that use signals when it's really not appropriate, but that's not the signal API's fault.

For process management, all the terrible problems that make the APIs impossible to use safely are totally self-inflicted. And probably the worst of those is the choice to use signals!

If we're kvetching about kernel API misdesigns, "non-blocking read from stdin" should also be on the list, probably just below SIGCHLD. The problem is: how do you do a non-blocking read from stdin, like you might want to in an async system like node? You might think "well, just use fcntl on fd 0 to set O_NONBLOCK", but since the O_NONBLOCK flag is stored on the file descript*ion*, this also affects any other processes that might have copies of that fd. Obviously O_NONBLOCK should have been a file-descriptor flag, like O_CLOEXEC, but file-descriptor flags didn't exist when O_NONBLOCK was created, so that's not how it works. Therefore, you can't safely set O_NONBLOCK on stdin without possibly breaking other random programs. djb has some cogent commentary: https://cr.yp.to/unix/nonblock.html

There are some obscure hacks for specific cases: https://github.com/python-trio/trio/issues/174#issuecomme...
Or really *really* obscure hacks: https://gist.github.com/njsmith/235d0355f0e3d647beb858765...

But fundamentally this is an obvious, common problem that simply can't be solved on popular Unixes.

(Probably the obvious solution for Linux at this point would be to add a RWF_NONBLOCK flag to preadv2/pwritev2, as per djb's suggestion.)