emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: igc, macOS avoiding signals


From: Pip Cet
Subject: Re: igc, macOS avoiding signals
Date: Mon, 30 Dec 2024 20:03:23 +0000

"Helmut Eller" <eller.helmut@gmail.com> writes:

> On Mon, Dec 30 2024, Pip Cet wrote:
>
>> IMHO, we now have three solutions that are still in the running (my
>> order of preference):
>>
>> 1. keep the current code and special-case some signals which are needed
>> for user responsiveness
>> 2. use the signal serialization thread you proposed
>> 3. use an allocation thread, but keep SIGSEGV on the main thread
>
> I think this is missing:
>
> 4. add callbacks to ArenaEnter/ArenaLeave to block/unblock signals

Everything that requires MPS modifications for all users (rather than
having a few users benefit from them, if they choose to run a modified
MPS) isn't on my list.

> Perhaps add 5. (or make it a variant of 1)
>
> 5. special-case some performance critical handlers and simplify all
>    others so that they are obviously harmless.

That's a "rewrite Emacs signal handling" project, not a "add MPS to
Emacs" project.  That said, I'm all for it.  The MPS part is definitely
subsumed by (1).

>    The SIGIO handler is an example for a harmless signal handler.
>    handle_alarm_signal seems harmless too.

It needs low latency, but not high throughput, AFAIK.  I consider that
part of "performance".

>    handle_interrupt_signal is definitely not harmless, but may not be
>    preformance critical.

That's meant to do unsafe things on some systems, IIUC.

>    So far SIGPROF seems to be the only performance cortical handler.

I wouldn't count out SIGALRM.

Pip




reply via email to

[Prev in Thread] Current Thread [Next in Thread]