Re: igc, macOS avoiding signals

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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).

Perfect. Please put my other mail about get_backtrace on hold.