Re: Helping with MPS

[Pip Cet <pipcet@protonmail.com>]

"Helmut Eller" <eller.helmut@gmail.com> writes:
> On Tue, Aug 20 2024, Pip Cet wrote:
>
>> My current workaround is to have a flag for each signal, plus a global
>> flag, and set them when the signal arrives at an inopportune time. We
>> check them when we know we just left MPS code, and that part usually
>> works, but sometimes we miss the exit, and then we have to wait until
>> the next 'maybe_quit' to handle the signal, and that strikes me as
>> potentially too long a delay.
>>
>> So, if you're using GNU/Linux machines, you might run into crashes we
>> already know about.  I can provide a temporary fix, but it doesn't feel
>> quite good enough for scratch/igc yet.
>>
>> Any comments or advice would be welcome, of course.
>
> What would you think about creating fork of MPS (on GitHub)
> that includes:

I'm not a huge fan of GitHub, to be honest.  There's already
https://codeberg.org/pipcet/mps, so maybe we can use that and mirror to
a GitHub repo if that's desirable?

> a) fixes for known problems:
>    https://github.com/Ravenbrook/mps/issues/285
>    https://github.com/Ravenbrook/mps/pull/257
>    https://github.com/Ravenbrook/mps/pull/38
>    https://github.com/Ravenbrook/mps/pull/83

I'll have to look through these.

> b) removes the instruction emulation on protection faults in the AWL
>    pool.  For us, this adds a lot of complexity with questionable gains:

I don't think it's questionable at all:  There is no advantage for us.

>    The weak hash tables implementation is, well, complicated and for the
>    marker-vector it's ineffective because there we use tagged pointers
>    (apparently without problems).

Hmm.  I suspect the reason we're not seeing any problems is that few
people test on i386, and that only certain instructions are emulated: in
particular, there has to be a nonzero offset in a load instruction for
it to be emulated.  Using a tagged pointer in a weak object with the
single access emulation is definitely not okay...

> c) blocks signals. Not my preferred solution, but some people seem to
>    think that that is the emacsy way to do things.

I'm not sure whether we should block signals or add "this thread is
trying to lock the arena"/"this thread is unlocking the arena"
callbacks, but that's an implementation detail.  It does feel like I've
been trying to hammer in a screw here :-)

d) adds support for Windows/GCC builds.

I think this is the right way forward (so you've convinced me; I've
previously expressed the opposite opinion), for these reasons:

1. it's the only sensible way of supporting i386, because the single
access restrictions are too much of a problem, and virtually untestable
because they trigger so rarely
2. it supports Windows/GCC configurations
3. I don't see a way to avoid delaying signal handlers until the next
maybe_quit(), at least some of the time, without it.

Pip