Thiago, thank you — that signal-safety framing is sharper than the one I'd been using, and I'd like to adopt it. "Asynchronously reentrant at any point, which rules out anything that goes through malloc() or locks a mutex" captures the intent better than "doesn't wait," and it lines up exactly with what the effect is meant to guarantee. The four-way disentangling (thread-safe / reentrant / signal-safe / nonblocking) is also a cleaner taxonomy than I had — Bjorn's reentrancy question and your answer together draw the lines well.
On the name: I agree it's a poor one, and the O_NONBLOCK collision is a third clash I hadn't even listed (the other two being the RT "doesn't wait" sense and the lock-free/wait-free *progress* guarantee — three different meanings for one word).
My only reason for leaning toward keeping it is migration: Clang already ships [[clang::nonblocking]] with exactly this meaning, and libc++ has started annotating with it, so a divergent name would fork from a deployed, in-use spelling. That's a real cost, but I don't think it's decisive, and I'd genuinely rather land on a name people can live with than defend this one.
So — does anyone have a spelling that says "signal-safe in the [support.signal] sense, as a checked property of the function type" without colliding with O_NONBLOCK, lock-freedom, *and* thread-safety? I'd weigh a clearly better name against the Clang-divergence cost happily. (signal_safe itself is tempting given your framing, though it arguably overspecifies the mechanism.)
- Michael