Re: igc, macOS avoiding signals

[Eli Zaretskii]

> Date: Tue, 31 Dec 2024 14:29:18 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, spd@toadstyle.org, 
> emacs-devel@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >> maybe_quit is not a great safe point, it's just the best we have.  It's
> >> insufficient if Emacs becomes idle, and how often we call rarely_quit
> >> is quite unpredictable.
> >
> > What about doing that from process_pending_signals?
> 
> Yes.  The rest of this email is a half-hearted defense of why I didn't
> do that right away.
> 
> We certainly want to call it from unblock_to if the count reaches (I
> think that's what you meant?), but I wasn't convinced we wouldn't need a
> shadow signal mask for that.
> 
> Merging the pending_signals flag in keyboard.c and the one in igc.c (if
> that's what you meant) sounds like a good idea, too, but needs some more
> thought: if we handle some signals while input is blocked, but not
> others, what should pending_signals be?

We'd need to add a new function to process_pending_signals, which
would process SIGPROF and maybe also SIGALRM.  The signal handlers for
those would then only set a flag (not pending_signals, some other
flag).