Re: igc, macOS avoiding signals

[Sean Devlin]

Hi Pip,

> On Dec 29, 2024, at 1:29 AM, Pip Cet <pipcet@protonmail.com> wrote:
> 
>> I'll try to come up with a patch.
> 
> This should provide some data (on stderr) about which signals we delay,
> and for how long (the "delayed" messages).  It also includes some
> information on additional points at which we can detect whether signals
> are pending (the "delaying" messages); it's probably safe to run them at
> that point, but the code might need some changes because other signals
> (or even the signal in question) might be legitimately blocked when we
> reach that point.
> 
> If the "delaying" messages indicate acceptable (initial) delays, we
> might get away with simply calling gc_maybe_quit more often.  If they
> don't, further fixes will be necessary, or we need to find more such
> points.
> 
> On POSIX systems where we can spare an additional signal, we can run a
> separate thread to ask us to retry running signal handlers when the
> arena lock might be available again.
> 
> Or we could move to a separate thread for slow-path allocations.
> 

I’ve built Emacs with your patch. After running Emacs -Q for a few minutes, I 
can confirm I see a few log statements:

delaying 20 for 0.066594 sec
delaying 20 for 0.066612 sec
delayed 20 for 0.066614 sec

Please let me know if there are any particular tasks you’d like me to try, or 
if I should just collect the logs in the background during general usage.

Cheers.