Re: MPS: Win64 testers?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 23 Aug 2024 15:51:41 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: sebastian@sebasmonia.com, kien.n.quang@gmail.com, emacs-devel@gnu.org, yantar92@posteo.net
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >> So I think this could improve Emacs in general, even for people who will
> >> never use MPS.
> >
> > We are not coding Emacs from scratch.  Emacs is already a very large
> > body of code, most of it tested by time and gobs of users and use
> > patterns.  To start rewriting too much of that means we are losing all
> > that hard-earned stability, because many corners in Emacs code are not
> > well known to those who are currently active in development and
> > maintenance.
> >
> > So from where I stand, it is definitely a significant problem to make
> > such vast changes, and the fact that it will help us eventually
> > doesn't help.  Because if we destabilize Emacs enough, we will lose
> > our users, which are the only reason Emacs is still alive and kicking.
> 
> I don't see how we'd destabilize the existing Emacs code by making such
> changes; any unconverted code would continue working as it did before
> without MPS, and continue not working with MPS.

I'm talking about the code changes, not about what stays unchanged.

And if you don't understand how adding a lot of changes of this
particular kind can destabilize Emacs, then I guess we have very
different perspectives on stability, and this line of discussion
between us is not useful.

> If your point is that it might be a long time until MPS is stable enough
> for very unusual configurations, that is certainly true, and affects
> when it's a good idea to enable it for general use.

Not "for very unusual configurations", for all configurations,
including the most popular ones.  We are touching the most delicate
parts of Emacs, and will probably touch a lot of them (unless we find
some simpler, more reliable way of preventing these problems).

> >> This particular call is safe.  'match_data' lives on the stack, MPS
> >> treats the stack conservatively as pinning every object to which it
> >> might possibly refer, thus 'match_data->pattern' cannot be moved.
> >
> > IOW, we are lucky.  Because match_data could well be a global variable
> > allocated off the heap, or something else.
> 
> Which would be a bug both with and without MPS, as nothing protects
> match_data.list from GC if it doesn't live on the stack.

??? We have gobs of those, and know how to protect them.  The easiest
way is staticpro, and there are others.

> >> The change I proposed is redundant: it tells MPS not to move the
> >> pointer, and it uses a pointer-to-a-pointer to catch potential moves.
> >> Only one part of that is needed, but in both cases, we need to remember
> >> to un-pin/free something.
> >
> > If the change is redundant, why did you propose it?
> 
> Better to solve a problem twice than not to solve it at all?

Not in my book, no.  Since Emacs is stable, we should not add any code
that is not strictly necessary, otherwise we risk unnecessary
problems.

> I don't see a problem there, to be honest.
> 
> (It's morally equivalent to writing
> 
>   if (p)
>     xfree (p);
> 
> even though that's redundant as well.)

It's nowhere morally equivalent to the above, because it is much
harder to understand what goes on with MPS than to figure out that
xfree tests NULL internally.