Rethinking race-free process signaling

Posted Apr 8, 2019 22:08 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: Rethinking race-free process signaling by rweikusat2
Parent article: Rethinking race-free process signaling

> Problem solved
Nope. And you haven't even gotten to the interesting stuff - multithreading and realtime signals.

Signals are basically impossible to use correctly.

to post comments

Rethinking race-free process signaling

Posted Apr 9, 2019 14:18 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link]

Feel free to prove my wrong instead of making (wrong) blanket assertion based on not knowing how to handle something I didn't explicitly mention. Eg, describe specific problem situation. The model I described maps naturally to multithreaded processes as well, it just needs to be applied to all threads --- they either block signals which are supposed to be handled or block inside a multiplexing call which atomically unblocks said signals. There's nothing special about realtime signals beyond that they can be queued and that it's possible to send some data alongside a signal.

With Linux, one can even build programs which are entirely signal-driven by using realtime signals for I/O readiness notification (see fcntl(2)) and sigwaitinfo instead of one of the file descriptor based I/O multiplexing calls. I've used that once for a moderately complex Perl program (about 25 kloc) because it was the easiest to use in this environment.

Rethinking race-free process signaling

Posted Apr 9, 2019 15:04 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

Let's make it really fun: asynchronous signals and asynchronous cancellation handlers, because having one horrible source of bugs that trigger very rarely when innocent functions like malloc() are called anywhere in the call stack was not enough, so they added another! (Unfortunately asynchronous cancellation handlers *are* used, as Debian code search makes clear, so libc authors have to go through hell making them work right: this is distinct from, say, seekdir(), which appears to be basically unused, with all the codesearch hits being wrappers or parts of the implementation.)

Rethinking race-free process signaling

Posted Apr 9, 2019 17:42 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (2 responses)

Signals don't cause "horrible bugs when innocent functions like malloc are being called". Broken code for handling signals might. As I already wrote: A signal handler must not call a function which isn't async signal safe it it interrupted another unsafe function. That's easy enough to guarantee (see other postings),

In the presence of signals, all functions defined by this volume of POSIX.1-2017 shall behave as defined when called from or interrupted by a signal-catching function, with the exception that when a signal interrupts an unsafe function or equivalent (such as the processing equivalent to exit() performed after a return from the initial call to main()) and the signal-catching function calls an unsafe function, the behavior is undefined.

That's part of section 2.4.3 of the following page:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04

The three usual approaches would be

call only safe functions from signal handlers (eg, by using a pipe to notify an event loop of a signal)
keep signals blocked unless a safe function is being executed (what I described)
keep signals blocked and dequeue them synchronously via sigwait and friends

A UNIX signal is nothing but a level-triggered interrupt emulated in software. A lot of hardware (eg, PCI hardware) has used this model for event notification for an eternity and it's perfectly workable.

IMHO, thread cancellation is a braindead misfeature but that's a completely different discussion.

Rethinking race-free process signaling

Posted Apr 11, 2019 7:04 UTC (Thu) by wahern (subscriber, #37304) [Link]

I think the better analogy is edge-triggered interrupts. The real headache with signals is setting up the environment as you describe, and that's problematic because the timing and disposition semantics are quite inconvenient.

Once all the boilerplate code is in place it's seems like alot of unnecessary complexity compared to having started with something like a signalfd or eventfd. OTOH, for some things, such as catching SIGSEGV to extend mmap'd stack data structures, or to interrupt and switch program flow without tight, language-level integration of components, the old semantics are indispensable.

Threading semantics compound the headaches. But as for cancelations in particular--I don't think anybody defends the idea any longer. It's almost a strawman at this point as few if applications actually use them and implementations effectively disclaim liability. I'm surprised there's no movement to remove cancellations from implementations, POSIX, or both.

Rethinking race-free process signaling

Posted Apr 13, 2019 14:59 UTC (Sat) by nix (subscriber, #2304) [Link]

That's easy enough to guarantee

It's so easy to guarantee that when I looked, every single program that used nontrivial signal handlers (that did more than assigning to a variable or writing to a one-byte pipe) got it wrong, including glibc itself. The latter case is since fixed, but this is clearly not easy to guarantee, given that most uses are faulty and even the implementation gets it wrong. I suspect lack of experience on your part masquerading as arrogance, frankly.