Re: Some experience with the igc branch

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

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

>> Date: Sun, 29 Dec 2024 12:39:53 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org
>>
>> >> Instead, we call the SIGSEGV handler directly on the other thread,
>> >> passing in the same siginfo structure.
>> >
>> > How can we call the SIGSEGV handler directly from another thread?  And
>>
>> It's a C function.  We call it.
>
> We need to know its name or its address to do that.  It is not our
> function.

sigaction gives us the pointer.

>> > how will that thread know it needs to call the handler in the first
>> > place?
>>
>> We'd like to just use pthread_cond_signal, but to be POSIXly correct we
>> need to do so from another thread.
>
> Ouch!

There are ways around that, but I'm liking this aspect less and less.

Effectively, macOS and Windows run the exception handler with signals
blocked (Windows doesn't have any; the macOS exception handling
mechanism blocks signals on both threads, IIUC).  If we do the same on
POSIX, by adding all Emacs signals to the sigmask for the MPS SIGSEGV
action, it should be safe to leave it in place.  (We would still need to
leave the MPS signals unblocked, of course).

I *think* that's still safe, but I have to think about it some more.

As for the current scratch/igc code, we could use it and fix it one
signal at a time.

SIGIO/SIGPOLL don't need to be delayed
SIGPROF doesn't need to be delayed if it simply records "in GC"
SIGCHLD: already fixed by Helmut.  If that fix is unacceptable, we
can clear delayed SIGCHLD signals before we create a new
process, which would mean Emacs doesn't use extra PIDs.
SIGALRM: difficult.  Does this need to run on the main thread?
I'll have to look at the code.
SIGINT, SIGUSR*: very difficult.

>> >> > how will it know which MPS function to call?
>> >>
>> >> The MPS SIGSEGV handler is obtained by calling sigaction.
>> >
>> > That's unreliable: it assumes that no one else calls sigaction after
>> > MPS, or changes the chain of handlers in some other way.
>>
>> It merely assumes that any such modifications call our signal handler
>> with the right arguments, which is precisely what MPS assumes anyway.
>
> Sorry, I don't follow.

Let's delay this particular discussion until we actually have decided
the other problems aren't severe enough to kill the allocation thread
proposal?

Pip