Re: Some experience with the igc branch

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

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

>> Date: Sat, 28 Dec 2024 21:05:43 +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
>>
>> "Eli Zaretskii" <eliz@gnu.org> writes:
>>
>> > By
>> > contrast, under your proposal, MPS should be called from a separate
>> > thread.  However, the way we currently process signals, the signals
>> > are delivered to the main thread.  So we should install our own
>> > SIGSEGV handler which will run in the context of the main thread, and
>> > should somehow redirect the handling of this SIGSEGV to the MPS
>> > thread, right?
>>
>> Correct.
>>
>> > So now the main thread calls pthread_kill to deliver
>> > the SIGSEGV to the MPS thread,
>>
>> No, that wouldn't work.  We need the signal handler to have access to
>> the siginfo_t data, and pthread_kill provides no way to include that
>> information.
>>
>> 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.

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

>> (My original code simply accessed a byte at the fault address; however,
>> reading the byte isn't sufficient, and writing it risks exposing
>> inadmissible intermediate states to other threads, so now we call the
>> sa_sigaction function directly).
>>
>> > but what will the MPS thread do with that?
>>
>> Call the MPS SIGSEGV handler, which knows what to do based (currently)
>> only on the address.
>>
>> > 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.

> Also, on MS-Windows MPS doesn't use a signal handler (because there
> are no signals on Windows, really).  It uses an exception handler, and

Can exception handlers be interrupted by emulated signals running on the
same stack?  If they can't, we don't need to worry about this part for
Windows.  If they can, though, back to the drawing board :-)

> But if this is not relevant to those conditions (which I frankly don't
> understand why they are needed), then we could stop arguing about that
> aspect.

We still need to decide whether there should be a way for code to assume
no GC can happen.  If it should be possible, we need to spell out when
that assumption can be made.

Pip