Re: Some experience with the igc branch

[Eli Zaretskii <eliz@gnu.org>]

> 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
how will that thread know it needs to call the handler in the first
place?

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

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
I don't think there's a documented method of getting at the handler
after installing it.  So we'd probably need to call the MPS function
directly, leveraging our knowledge of the MPS internals.  That's
assuming we can call the exception handler outside of the context of a
real exception, which I'm not at all sure we can.

In sum, this part of your idea, of simulating a segfault/exception due
to access to protected memory, sounds to me to be quite fragile and
unreliable.

> >> >> 4. we don't trigger memory barriers
> >> >
> >> > Same question here.
> >>
> >> I meant all four conditions are necessary, not that any one of thew
> >> mould be sufficient.
> >>
> >> GC can happen if another thread triggers a memory barrier OR another
> >> thread allocates OR we hit a memory barrier OR we allocate.  The
> >> question is whether it is ever useful to assume that GC can happen ONLY
> >> in these four cases.
> >
> > GC can also happen when Emacs is idle, and at that time there's no
> > allocations.
> 
> If you want to spell it out, sure, but there's no way for the main
> thread to become idle without potentially allocating memory, so this
> fifth condition is redundant.

I don't understand why the assertion "there's no way for the main
thread to become idle without potentially allocating memory" is true.
Emacs becomes idle because there are no input events to process, and
that has nothing to do with allocating memory.  The GC we trigger when
Emacs is idle might find that there's no garbage to collect, but AFAIU
it will nevertheless take the arena lock.

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.