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 …
Once a handler returns (observable by raise returning in the abort implementation), though, it's mandated that program termination happen as if by SIGABRT, so there's really no concurrency issue at this point. Another thread calling abort is not sequenced wrt the sigreturn, so...
-
-
...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 -
-
-
Hmm. If thread A raises a signal that it has blocked, but thread B does not have it blocked; and a signal handler is installed; does the signal handler run in thread B and does raise() only complete when thread B is done?
-
No. raise() makes a signal pending for thd calling thread not the process.
-
Yeah that's where my research took me. I need to brush up on all the POSIX requirements and do some full testing of my implementation (which I think is mostly correct, but lacks features) and existing systems. Thanks for the answer!
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.