On Dec 29, 2024, at 9:22 PM, Pip Cet <pipcet@protonmail.com> wrote:

"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