Re: MPS: Win64 testers?

[Pip Cet <pipcet@protonmail.com>]

"Eli Zaretskii" <eliz@gnu.org> writes:

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

Which ones do you mean?

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

Simpler, maybe, but reliability, I will keep insisting, improves if we
think about why it's safe to hand off a pointer to GCable memory to an
externable library.

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

My point is you'd have to protect it, albeit slightly differently, with
or without MPS.  Not that much changes with MPS, and to say it works
because "we are lucky" is inaccurate.

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

The master branch may be, but there's nothing wrong with keeping our
options open on scratch/igc rather than leaving in a few "redundant"
safety checks.

I agree, though, that a comment is in order here.

Pip