Re: igc, macOS avoiding signals

[Pip Cet]

"Helmut Eller" <eller.helmut@gmail.com> writes:

> On Sat, Jan 04 2025, Eli Zaretskii wrote:
>
>>> WDYT?
>>
>> I'd make these extra calls only call the SIGPROF handler if the
>> counter says some signals were missed.  There's no need to affect
>> other handlers without a good reason.
>
> If I had my way, I would merge Vquit_flag and pending_signals into a
> word-sized bitset like so

Bitfield access isn't atomic even on x86_64, thus the array-of-ints in
the current code.

> union pending_signals {
>   uintptr_t sigset;
>   struct {
>     uintptr_t quit:1;
>     uintptr_t profiler:1;
>     uintptr_t child:1;
>     uintptr_t alarm:1;
>     uintptr_t io:1;
>     /* other signals */
>   } s;
> } pending_signals;
>
> Then maybe_quit and process_pending_signals would be merged into a
> single function that look like this:
>
> void
> process_pending_signals (void)
> {
>   union pending_signals signals = pending_signals;
>   if (signals.sigset)
>     {
>       pending_signals.sigset = 0;

This is really

  union pending_signals new_pending_signals = pending_signals;
  new_pending_signals.sigset = 0; <--- HERE
  pending_signals = new_pending_signals;

If a signal handler strikes at the marked location, and sets a bit, then
that bit will be unconditionally cleared by the last line.

> If no signal is pending, this only needs to load and test one word
> instead of two.  If only one signal is pending, then it only calls that

I agree we should set pending_signals when we set Vquit_flag (and merge
global_igc->signals_pending and the existing flag), and simplify
maybe_quit that way, but that is an optimization only.

If you want to access individual bits atomically, you need to use an
atomic type, and have a workaround for machines without lock-free
atomics.

> handler.  For the rest, I'd hope that a modern branch predictor
> determines quite accurately which handler will mostly likely be called.

Sounds like PGO, which we can do as soon as we have a representative
simulated work run.

Pip