Re: igc, macOS avoiding signals

[Pip Cet]

"Sean Devlin" <spd@toadstyle.org> writes:

> 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:

Can you try setting igc-step-interval to a small float value, like 0.05
?  As long as it's just a few messages, I don't think it'd cause
significant problems, but maybe enabling the background work would do
something.

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

Repeatedly hitting "s" in an M-x igc-stats buffer should cause more
messages, but that uses IGC in an atypical fashion, so I'm not sure
that's actually useful data...

Thanks!

Pip