emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: igc, macOS avoiding signals


From: Helmut Eller
Subject: Re: igc, macOS avoiding signals
Date: Sat, 04 Jan 2025 15:55:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

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

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;
      if (signals.s.quit)
        process_quit_flag ();
      if (signals.s.io)
        handle_async_input ();
      if (signals.s.alarm)
        do_pending_atimers ();
      if (signals.s.profiler)
        process_pending_profiler_signals ();
      /* other signals */
    }
}

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
handler.  For the rest, I'd hope that a modern branch predictor
determines quite accurately which handler will mostly likely be called.

Helmut



reply via email to

[Prev in Thread] Current Thread [Next in Thread]