This is opposed to calling `sigwait` or similar to actively suspend and wait for a signal, which is not possible to do here.
Granted, it may be that the stars align and their implementation works in practice, but that does not make it any less bizarre.
UNIX signals are in no way or form direct translations of hardware CPU traps. The kernel handles hardware traps, which may or may not lead to UNIX signals. Heck, with userfaultfd, a different userspace process could be handling, or injecting, the fault! Not to mention VMs, where the the guest userspace is very far away from any real hardware traps.
There are basically two classes of UNIX signals: Signals that indicate that you might need to take some action (SIGTERM, SIGALRM, SIGUSR1, ...), and signals that indicate that your process did something illegal (SIGILL, SIGSEGV, SIGFP, ...). There is a very, very limited number of cases where handling these errors make sense, and trying to be "clever" to make (faulty and ill-advised) performance optimizations is not one of them.
> This did not improve performance, it was just an unnecessary hack
Well, the Android VM certainly uses a signal mechanism for safepoints and stack overflow checking, for a reason (https://android.googlesource.com/platform/art/+/master/runti...) (both latency and code size), so don't sit there and tell me that the VM running the world's most popular OS is pessimizing itself pointlessly.
> The kernel handles hardware traps, which may or may not lead to UNIX signals.
Not all traps result in signals, and not all signals are traps. Nevertheless, the POSIX signals API is the means through which Unix OSes provide user programs the ability to interact with CPU traps. (Windows does the same thing, morally, with SEH and vectored exception handling --- https://learn.microsoft.com/en-us/windows/win32/debug/vector...). Any decent OS should provide applications with the tools they need to make full use of the underlying hardware. All these anti-signals people are just arguing that programs be bigger and slower, because they can't make full use of all the hardware features of the system, out of, ultimately, an aesthetic objection to signal handling.
Ill-advised as per the authors decision to remove said hack as it brought none of the intended benefits. Or are you suggesting that your opinion is more valuable than the authors whose code we're discussing?
Be careful with fallacies suggesting only one side of an argument is based on opinions. :)
For example, one kind of program organization that used to be more common in Unix but that remains legal involves keeping signals masked all the time except around certain blocking system calls, e.g. ppoll, that atomically unblock signals and wait. In such a program, a signal can arrive only inside the blocking system call and so the handler can call regular functions without the usual strictures of asynchronous signal safety. (Consider responding to SIGWINCH, which tells you about changing terminal size.)
Synchronous signals are also special in that they're, well, synchronous. That means that in the signal handler you can examine the target memory address or instruction pointer and take action specific to a given spot in your program --- e.g. longjmp to an error handler.
All of this is useful, safe, and legal under POSIX. The main problems with POSIX signals are that, 1) as this thread underscores, most people don't understand them, and 2) signal handlers are process global and hard to share. (Consider if you're running two VMs in a process and each wants to use a SIGSEGV GC safe point trick.)
(userfaultfd, sadly, requires more system calls than a synchronous signal handler to handle anomalous memory access.)
We should be enhancing POSIX signals to make them easier to share, not casting aspersions on them.
... As long as the called functions are fully async-signal-safe/reentrant. It used to be even more sensitive, in that not all register state was correctly saved/restored on Linux.
(On the fabled plan9, where signals are replaced with arbitrary-text "notes", the issue is even bigger as floating point registers are not saved/restored)
> We should be enhancing POSIX signals to make them easier to share, not casting aspersions on them.
That's fair, but they have already been fixed with signalfd, which more modern processes use to deal with the few POSIX-isms that require it, but many of the original uses have been superseded.
E.g., few modern applications use `timer_create` and SIGALRM, as they can instead use timerfd or poll with strategic timeout (although usually abstracted away by their eventloop). SIGBUS is a POSIX-way to deal with mmap truncation, but sealed memfds can be used to avoid the issue altogether. SIGUSR1/2 can be replaced by any IPC mechanism to give much more flexible controls than a single "reload"/"toggle" signal.
(The POSIX ways can still be useful in certain simpler programs of course.)
