Re: Helping with MPS

[Pip Cet]

"Jonathon McKitrick via \"Emacs development discussions.\"" 
<emacs-devel@gnu.org> writes:

> I'm going to run MPS on my personal and work machines,

Thank you, that's great to hear!  May I ask which operating system and
CPU architecture they use?

> and I'll report back here if I have any issues.

Please do!  Any feedback is appreciated.

> I'm also happy to help with coding and docs if needed.

Well, it's time to fix the remaining stability issue: signal handlers
and MPS.  I've been running a workaround for weeks now, and I've
attributed all the remaining crashes to other causes, so I think it's
stable, but it's not particularly clean.

The problem is signal handlers may interrupt MPS, and then we must not
touch any Lisp data, so we must (usually) delay running the signal
handler until we've left MPS code.  The problem is MPS code may be
entered transparently by another thread, and then we don't know that
we're leaving MPS code...

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.

> First question: Since the build succeeded and emacs is running
> smoothly, what's the easiest way to confirm that my executable
> definitely has MPS running?

Attach gdb and wait for a segfault.  If you can continue and Emacs keeps
running, you're running MPS.

'M-x igc-stats RET s' should also work, and show a snapshot of MPS
allocations.  Just leaning on 'c' for a while in that buffer (which
triggers a collection) has produced crashes in the past...

Thanks again
Pip