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: Eli Zaretskii <eliz@gnu.org>,  ofv@wanadoo.es,  emacs-devel@gnu.org,
>>   eller.helmut@gmail.com,  acorallo@gnu.org
>> Date: Wed, 25 Dec 2024 06:23:49 +0100
>> 
>> > If they don't have separate stacks, and we interrupt MPS, the signal
>> > handler cannot look at any MPS-modifiable memory (including roots, which
>> > may be in an inconsistent state mid-GC), ever.  This includes the
>> > specpdl.  We can't write to MPS-known memory, ever.  This includes any
>> > area we might want to copy the backtrace or specpdl to.
>> 
>> And I don't think that's right :-). It's completely right that in the
>> SIGPROF handler everything can be inconsistent. That's true both for MPS
>> and Emacs. For example, the bindings stack (specpdl) may be inconsistent
>> when SIGPROF arrives.
>
> Theoretically, maybe.  But in practice, you'd need to identify the
> code which manipulates specpdl that could have specpdl in inconsistent
> state if interrupted at some opportune point.  Can you identify such
> places in the code?

Which is basically what I answered to Helmut in another sub-thread.

...

>> For me, it's not about a theoretical or even practical solution that
>> somehow ensures a consistent state in MPS, or some future changes in MPS
>> or something. It's about getting away with what we do in the profiler
>> _now_, as we do with the old GC. which is already seeing potentially
>> inconsistent state in Emacs' memory.
>
> See above: there's a difference.  So I would really like to hear why
> you think accessing specpdl from a SIGPROF handler in an igc build is
> safe.

I tried to answer your questions in a different reply sent a few minutes
ago.