I finally worked out how to make abort() conforming when SIGABRT's disposition is under aggressive alteration by other threads, and it's gloriously simple. Especially if you've ever read the (utterly wrong) glibc monstrosity: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/abort.c;h=9bb97c10552223a65f2a423cb6d5ad184fad5438;hb=HEAD …
...it's possible that a concurrent abort from another thread may still have a small window to run, but this situation is not observably different from signal handler still being about to return in the first (or abort not yet entered, if first has SIGABRT blocked).
-
-
So I think we're in an agreement that a program handling SIGABRT, which may have multiple threads (perhaps through libraries), needs to synchronize in the signal handler if it can't safely be run concurrently/multiple times.
-
Yes, but normally a library making threads that are supposed to be transparent to the application needs to block all signals in those threads anyway, and of course not do things that would terminate the process, which is rather non-transparent. :-)
-
I need to write that libraries(7) manual page for Sortix that documents these best practices. I forgot what the that page was called on Linux.
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.