> On Dec 29, 2024, at 9:22 PM, Pip Cet <pipcet@protonmail.com> wrote:
> 
> "Sean Devlin" <spd@toadstyle.org <mailto: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.

Sounds good, will do.

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

Well, I can definitely make it log a bunch of messages either by running the profiler or by spawning subprocesses. Is that helpful by itself, or do I also need to generate garbage for collection?

> 
> Thanks!
> 
> Pip