Is an uncatchable SIGABRT better than a[n unintentionally] catchable SIGSEGV/SIGILL (which varies by arch) when dangerous/corrupted process state is detected? https://www.openwall.com/lists/musl/2018/09/17/2 …
It would be nice to have a syscall to do it all faily-safe and atomically, but in the absence of one I was pretty happy to find a solution that works this well for abort, and it still seems better than the status quo for where a_crash() is currently used.
-
-
Sortix currently implements abort() with exit_thread() (backend of _exit) that can atomically unconditionally exit and fake the exit code as if by a signal. I have considered doing it with scram(2). Question is how much alerting I want to go off on abort().
-
Neither exit_thread (undocumented) / scram(2) are necessarily long term interfaces, they were designed to reasonably solve the problem of the day and do it right. We shouldn't be afraid of adding new system calls to Linux if there's no reliable & simple way to do stuff in libc.
-
(Yes -- Linux ABI is long term, but there it's worth to discuss stuff through and come up with a long term good design from the start, and keep total kernel + userland complexity in mind)
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.