Re: igc, macOS avoiding signals

[Pip Cet]

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

>> Pip Cet <pipcet@protonmail.com> writes:
>>
>> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> >
>> >> This is about commit
>> >>
>> >> ceec5ace134081b64dbf46c4fb5702ef5209c5fd
>> >> Avoid MPS being interrupted by signals
>> >>
>> >> I've been running with this for some days now, and must report that
>> >> Emacs feels a _bit_ different here in interactive use, maybe one could
>> >> say not as smooth. (macOS, --without-ns, in my fork of Emacs, which is
>> >> very recent master++).
>> >
>> > I think we should quantify that.  Set a watchpoint on
>> > igc_global->signals_pending, check how often we even set that, and how
>> > often we call igc_maybe_quit, particularly if we were previously idle.
>> > Maybe it's sufficient to call it again from the idle handler.
>> >
>> >> After reverting the commit, it's feeling smoother again.
>> >
>> > Entirely possible.  Let's measure it.
>>
>> I'm sorry, but I pass. It's too time-consuming for me. Maybe someone
>> else using macOS can do that. I just wanted to make you aware of this.
>
> I can take a stab at this. I’ve been running the scratch/igc branch on macOS 
> using the NS build.

Thanks!

> To be clear, I should make sure to include the above commit in my build? Or 
> should I not include it?

I think we probably need to put instrumentation in the source code, so
we gain some idea of how long signals are delayed for when we mark them
pending.

(I'm also noticing that igc_maybe_quit isn't called as much as I thought
it would be.  Maybe we need to call it explicitly when Emacs becomes
idle?)

I'll try to come up with a patch.

Pip