Re: igc, macOS avoiding signals

[Eli Zaretskii]

> Date: Sat, 28 Dec 2024 20:54:03 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: spd@toadstyle.org, gerd.moellmann@gmail.com, emacs-devel@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >> Date: Sat, 28 Dec 2024 19:20:40 +0000
> >> From: Pip Cet <pipcet@protonmail.com>
> >> Cc: spd@toadstyle.org, gerd.moellmann@gmail.com, emacs-devel@gnu.org
> >>
> >> "Eli Zaretskii" <eliz@gnu.org> writes:
> >>
> >> > 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.
> >>
> >> SIGSEGV is never delayed in any proposal I'm aware of.
> >
> > The call to gc_signal_handler_can_run is inside
> > deliver_process_signal.  Are you saying that deliver_process_signal is
> > not called for SIGSEGV?
> 
> MPS installs its own SIGSEGV handler which doesn't go through
> deliver_process_signal.  Only if it fails, the Emacs handler which does
> go through deliver_process_signal is restored for the final SIGSEGV
> which will then terminate Emacs.

Then I ask once again: how can we explain what Gerd reports about
responsiveness if your changes, which only affect
deliver_process_signal, cannot affect MPS?

> >> > And AFAIU, on macOS there's no SIGSEGV anyway, is that right?  So why
> >> > does this delaying affect responsiveness?
> >>
> >> Possibly SIGPOLL.
> >
> > We don't need to block SIGPOLL, either.  Its handler is safe, the same
> > as SIGIO.
> 
> Thanks!  That's good to know, and that's why we pass the signal number
> to gc_signal_handler_can_run.

But currently gc_signal_handler_can_run does nothing with the signal
number except recording that it happened.  IMO, it should return
'true' immediately unless the signal is SIGPROF, SIGCHLD, or SIGALRM.