On 05/07/2026 08:03, Thomas Munro wrote:
On Sat, Jul 4, 2026 at 11:15 PM Jelte Fennema-Nio <[email protected]> wrote:
On Sat, 4 Jul 2026 at 02:51, Thomas Munro <[email protected]> wrote:
We don't actually care about the threads
themselves, and it doesn't seem that great if we have to introduce an
IPC ping-pong of some kind with each thread.
Agreed. But I do agree with Heikki that swapping out stderr seems pretty
hacky. At the very least because now the main thread cannot write to
stderr either anymore (which is why you removed the "terminated by user"
write I guess).
How about instead we do something like the attached?
That's definitely nicer, if we know that all potential error logging
caused by cancellation happens in a context that can check the flag.
+1, much nicer!
I didn't even look into that, because I was deliberately trying to
avoid needing atomics from here, because I need this to work on Unix
too, and I didn't want to open too many cans of worms at the same
time. Hence the appeal of a simple async-signal-safe system call that
has the right concurrency properties already and works also on Windows
without a separate code path. But... reaching for the can opener...
1. If we're ready to drop VS < 2022 and GCC < 4.9, we could just use
<stdatomic.h> directly in frontend code (independently of the project
to use it in the backend).
2. If we're not ready yet we could make "port/atomics.h" or selected
parts of it frontend-allowed.
3. Maybe all we really need for this case is memory barriers, and we
could move those out to a frontend-allowed header.
To be honest, I didn't realize we didn't allow "port/atomics.h" in
frontend code. I think spinlock-simulated 64-bit atomics is the only
thing that wouldn't just work.
- Heikki
