Re: igc, macOS avoiding signals

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 28 Dec 2024 20:50:22 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: spd@toadstyle.org, gerd.moellmann@gmail.com, emacs-devel@gnu.org
> 
> > > What do we expect to learn from this,
> > 
> > It tests the current code, which does this:
> > 
> > When a signal arrives, and we can't handle it because we might have
> > interrupted MPS, we mark the signal as pending in the igc structure.  At
> > some point later, we check the igc structure for pending signals,
> > reraise them, and unmask them.
> > 
> > Gerd's experience suggests that the "some point later" happens too late.
> > This patch gives us measurements.
> > 
> > It's unrelated to the OS scheduler, AFAICS.
> 
> Ah, okay.  I note that if we'd block signals when calling MPS and
> unblock on exit, then these delays couldn't have happened, AFAIU.

But OTOH, if this delaying of a signal affects responsiveness, then
all we need to do is exempt SIGSEGV from being delayed, right?  This
signal-delay mechanism was invented for SIGPROF, SIGCHLD, and SIGALRM,
but there's no reason to delay SIGSEGV.

And AFAIU, on macOS there's no SIGSEGV anyway, is that right?  So why
does this delaying affect responsiveness?

Or what am I missing?