Re: igc, macOS avoiding signals

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

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

SIGSEGV is never delayed in any proposal I'm aware of.  I don't see how
it could be, to be honest, but maybe I'm missing something there.

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

Possibly SIGPOLL.

Pip