Re: igc, macOS avoiding signals

[Pip Cet]

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

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

Pip