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


Am Mo., 8. Juni 2026 um 18:13 Uhr schrieb <
std-proposals-request_at_[hidden]>:

>
> 4. Re: Float the idea: First-class effect annotations and
> resource contracts for C++ (Thiago Macieira)
>
> Message: 4
> Date: Mon, 08 Jun 2026 09:13:19 -0700
> From: Thiago Macieira <thiago_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Float the idea: First-class effect
> annotations and resource contracts for C++
> Message-ID: <_Yo4kkUxThW1jM3N-XDGgQ_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> On Monday, 8 June 2026 04:50:20 Pacific Daylight Time Bjorn Reese via Std-
> Proposals wrote:
> > > A related concept that is very important in embedded systems is
> > > "re-entrant". A function is "re-entrant" if there can be more than one
> >
> > The standard calls this "signal-safe" -- see [support.signal] para 3.
>
> That's not exactly the same concept.
>
> A function is thread-safe if two threads can enter it at the same time. A
> simple way to implement this is to have a mutex so that only one can
> access
> common resources at a time.
>
> A function is reentrant if it can be entered more than once at the same
> time.
> If it's reentrant and thread-safe, it can be reentered by any thread,
> including the current, via recursion. It can also be reentrant but not
> thread-
> safe. But here's an important catch: this expects entering to happen at
> normal
> ABI boundaries of the *current* thread.
>
> A signal-safe function is one that can be reentered asynchronously in the
> same
> thread from any point in the function of the function, including any
> functions
> it calls. That excludes calling any functions that eventually end up in
> malloc(), because that is thread-safe but not signal-safe. In fact, any
> functions locking mutexes are usually not signal-safe. That's what the
> "nonblocking" attribute means.
>
> It's a horrible name because it collides with O_NONBLOCK.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 870 bytes
> Desc: This is a digitally signed message part.
> URL: <
> https://lists.isocpp.org/std-proposals/attachments/20260608/d99ecc8a/attachment.sig
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> ------------------------------
>
> End of Std-Proposals Digest, Vol 87, Issue 24
> *********************************************
>