Re: using C11's _Atomic()

On Sun, May 3, 2026 at 6:50 PM Dave Mitchell <[email protected]> wrote:

> This works ok because the signal handler and the interpreter can't be
> running simultaneously. But the threads module allows you to call:
>
>     $thread->kill('HUP');
>
> which emulates sending a signal to $thread by setting $thread's
> PL_sig_pending and similar variables.


IMNSHO this was a mistake, but I'm not sure we can fix that without
backwards compatibility concerns. A better implementation would send a
thread-directed signal (so that it can actually interrupt a syscall), but
that isn't supported on Windows (and I'm not sure how well it's supported
on older unices).

This isn't thread-safe: it locks
> the threads mutex before sending so that only one thread at a time can
> send a pseudo-signal to a particular thread, but the thread itself isn't
> locking a mutex each time it tests PL_sig_pending in PERL_ASYNC_CHECK(),
> nor when resetting it to false.
>
> It would be cost-prohibitive to lock a mutex each time the run loop tests
> PL_sig_pending, and insane to lock it within an OS signal handler.
>
> Atomic types fix all these issues.


Yeah, an atomic integer would fix that nicely. We may also want to wrap
atomic_fetch_add_explicit and atomic_store_explicit, because the default
memory order is stricter (and thus less performant) than is necessary here,
but probably that's an overkill in this case.

Leon