Re: Some experience with the igc branch

[Eli Zaretskii]

> Date: Thu, 26 Dec 2024 15:24:14 +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:
> 
> >> Date: Wed, 25 Dec 2024 17:40:42 +0000
> >> From: Pip Cet <pipcet@protonmail.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org, 
> >> eller.helmut@gmail.com, acorallo@gnu.org
> >>
> >> I haven't seen a technical argument against using separate stacks for
> >> MPS and signals
> >
> > You haven't actually presented it.
> 
> That's correct: we have an idea and a PoC, no design to discuss or
> anything close to a proposal, at this point.
> 
> My idea was to ask for obvious problems precluding or complicating this
> approach.

OK, but still, since you wrote the code to implement it, I guess you
have at least some initial design ideas?  I hoped you could describe
those ideas, so we could better understand what you have in mind, and
provide a more useful feedback about possible problems, if any, with
those ideas.

In general, as I wrote earlier, there's nothing problematic with
adding a C thread to Emacs.  But since (AFAIU) the suggestion is to
run MPS from that thread, I think we should understand in more detail
how can GC be run from a separate thread.  I expect that to have at
least some impact on the Emacs code elsewhere, since the original
Emacs design assumed that GC runs synchronously, and the rest of the
Lisp machine is stopped while it does.

> I've found a few minor things; so far, nothing unfixable, and no
> significant effects on performance, but the fixes will have to become
> part of the design and discussion.

Right, so I'm asking to describe these aspects, so that others could
consider them and possibly additional issues, and provide feedback or
raise concerns about that.

> I think rr (time-travel/reverse debugging with acceptable performance)
> support is important, but I think I'm the only one? It seems to be
> really slow on this branch, though I don't know how fast it is on
> scratch/igc.

Well, reverse debugging currently doesn't work on Windows, so at least
for that platform we cannot rely on that.