Dark Side of Posix APIs
vorner.github.io
vorner.github.io
The best solution I know is signalfd, a Linux feature. Block all the traditional signal handlers then epoll a signal file descriptor in a perfectly normal event loop. When a signal is received, it's possible to read instances of signalfd_siginfo from it. Even this has limitations such as being unable to handle SIGSEGV or SIGFPE.
The Android runtime library uses similar tricks for ANRs, with similar problems.
Signals are probably the most broken of all POSIX APIs.
What do you mean by that? Who else is there other than the process being signaled?
> Signals are probably the most broken of all POSIX APIs.
I agree completely.
> What do you mean by that? Who else is there other than the process being signaled?
A library that needs to be notified of certain signals and perhaps also their contents.
Know what you're doing? Set up signals yourself. Don't? Library sets it up for you.
No, you can definitely do it correctly.
Signals are more than one thing. They can be divided into three buckets:
* asynchronous, process-directed. When you press ctrl-C, the terminal driver generates a SIGINT to the process to handle at its leisure. It can be delivered to any thread of the process and isn't necessarily delivered immediately.
* asynchronous, thread-directed. pthread_sigkill sends this.
* synchronous, thread-directed. A null-pointer dereference (or other access to unmapped memory) causes a SIGSEGV to that specific thread. It's delivered immediately; letting the thread continue for a while first doesn't make sense.
* (synchronous, process-directed isn't a thing IIRC and wouldn't make sense)
Let's just talk about asynchronous, process-directed because that's what most people mean when they say signals.
There are low-level techniques to handle them correctly. If you have an event loop, my favorite is the "self-pipe trick". At process start time, create a pipe and set the O_NONBLOCK flag. Hold onto both ends. From the signal handler, write into the pipe (ignoring EAGAIN). In your event loop, read from the pipe. When there's something to read, a signal is pending. This gives you roughly the same thing as signalfd but is cross-platform.
The best high-level technique IMHO is to write your code in a language that has a common library for this stuff. The article is about signal-hook, which is commonly used in Rust.
That's nice. Seems good to me, similar to signalfd.
What if you don't have an event loop though? When I tried to learn this I couldn't find any sane way to use signal handler functions. There's just too many caveats. With event loops I can dedicate a thread to the task, the code executes in a normal context and everything works as expected.
> This gives you roughly the same thing as signalfd but is cross-platform.
Roughly? What are the differences? The most obvious to me is the fact I can read signalfd_siginfo structures from the file descriptor.
You can use my second-favorite technique: dedicate a thread to signals. Block the signals of interest, keeping them queued rather than running signal handlers. Do this early in main(), before spawning any threads, so that they'll inherit the block. Spawn a thread which dequeues in a loop via sigwaitinfo or sigtimedwait. Signal handling without a signal handler!
> Roughly? What are the differences [between the self-pipe trick and signalfd]? The most obvious to me is the fact I can read siginfo structures from the file descriptor.
That's the difference I mean. If you want to get those from the self-pipe trick, you need to do it yourself, dealing with the platform difference crap this article describes. Additionally, if you write more than one byte per signal, you'll have to be careful of half-written messages, since your signal handler can't block for capacity. (Why? It may be blocking the thread that does the reading, so it'd deadlock.) Maybe you'd have a separate buffer for the leftover part that doesn't quite fit, or ensure your your message size divides evenly into the pipe buffer capacity (see F_GETPIPE_SZ), or drop messages if there's insufficient capacity (use FIONREAD; the capacity shouldn't go down unless you're using the same pipe for multiple signals and don't have them masking each other out). Stuff like this can get complex but the basic technique of just ensuring ctrl-C reaches your event loop isn't that bad. You have to be very careful in the signal handler, but it's like five lines long, so life goes on.
Another difference is that installing a self-pipe handler lets you see the previous handler (if any). I've heard of chaining handlers to address complaints like kstenerud's about libraries. I've never actually wanted to share signals like that, but it's something one could try. Caveat: if you also want to uninstall signals, doing that out of order wouldn't go well.
https://github.com/jart/cosmopolitan/blob/7cbc2bc0838a88ff46...
I think I know everything that I'm supposed to do (on Linux, for example). But I wouldn't mind looking through an example that handles everything correctly. Something that is designed as an example, as opposed to reading through some much larger and older project.
The easiest way is just to set a variable to mark the occurrence of a signal and nothing else. Then check for changes from other parts of the program.
Also be sure to check every C library error result and the value that it was interrupted by signal occurrence, and eventually retry if needed.
Like most design by committee standards there is plenty of write once debug everywhere.
Are there any non-committee counter examples?
However in about 10 years that might not matter anymore.
If anything, I think Chrome will eventually split off into its own AOL, while the Web will continue on.
And sadly, Linux manages to do some of its own custom things here that makes it even worse. One thing I find helpful sometimes is being able to inspect the actual hardware trap number, which can help distinguish between a SIGSEGV caused by a pointer to memory that doesn't exist (which is the normal cause) or an unaligned memory access in an instruction that requires aligned access [1]. There's a field for it in siginfo_t, si_trapno... but Linux doesn't fill in si_trapno for x86 nor even provide it as a field to be provided, unlike the BSDs in both regards. However, Linux does helpfully provide the trap number in the mccontext_t struct... which is only accessible via the third argument of a signal handler, and not via any ptrace access for a debugger.
If I were to redesign signals, I'd start by dividing them up into two categories: synchronous signals and asynchronous signals. This division actually already exists, but only in terms of how a signal is dispatched; I'd extend it so that the details of what the signals look like and how they are handled are completely different.
Synchronous signals are those that are caused by processor interrupts (think a page fault), or some set of user-custom dispatchable signals (e.g., being able to request thread cancellation). These would be handled like a regular try/catch scope, although with additional opportunities for first-ditch and last-ditch handling--Windows SEH is the kind of programming model I'd go for. What this allows is being able to do something like "I'm going to call some custom code, and if it causes a segmentation fault, I can report an error and unwind the stack to code that's unaffected" (and possibly report a full stacktrace in the meantime, maybe even as the default handler if uninstalled). This kind of handling allows it to be scoped on a per-thread basis, unlike the current per-process signal handlers.
Asynchronous signals would instead be handled by inserting them into a per-process queue of unhandled signals. There would be some syscall for getting the next unhandled signal, and naturally something that could feed into whatever syscall you use for "wait until something interesting happens" (which on Linux would mean something akin to signalfd). At this point, dequeuing signals is now a relatively benign step, and you can handle this with a simple thread that does nothing but dequeues signals and sticks them into a thread-safe queue for other threads to check at their leisure. No more need to worry about async-signal-safety!
[1] Side side rant: On x86, Linux maps the #AC (alignment check) exception to SIGBUS. But #AC isn't used for SSE aligned vector move instructions, instead #GP is used. #GP is instead mapped to SIGSEGV, but Linux doesn't fill in many of the fields. (Not that I think x86 fills in the faulted address for a #GP exception, but still, no si_trapno field to easily distinguish a #PF SIGSEGV versus #GP SIGSEGV). It took me several hours of pulling my hair out before I realized I was getting #GP and not #PF...