Re: Some experience with the igc branch

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: pipcet@protonmail.com,  ofv@wanadoo.es,  emacs-devel@gnu.org,
>>   eller.helmut@gmail.com,  acorallo@gnu.org
>> Date: Wed, 25 Dec 2024 14:08:34 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > So why are those unsafe?  Because they access Lisp objects, or for
>> > some other reason?
>> 
>> What do you mean with unsafe? We are accessing an object's memory. That
>> memory may potentially be protected by a barrier.
>
> That's what I meant by "unsafe".  I'm still wrapping my head around
> this stuff, so apologies if I ask stupid questions.  

No reason to apologize. We're just working on getting onto common
ground, if that's an expression.

> Here's another one: why accessing the same object's memory that may be
> protected by a barrier OK from the main (a.k.a. "Lisp") thread, when
> MPS could have meanwhile started GC asynchronously? IOW, how is this
> "normal" access to Lisp objects different from access from a signal
> handler?

Under "normal" circumstances, in the main thread say, when we access an
object that is behind a barrier, MPS gets invoked (signal, Mach
exception), does its thing, removes the barrier, and lets the
application continue. So the application doesn't notice anything.

A problem occurs only, apparently (I've not read the MPS code), when the
barrier handling code in MPS is called while being in another signal
handler like Emacs' SIGPROF handler.

I don't know what exactly the problem is in the end, in MPS. That would
be a good question for Richard Brooksby, I think.