Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com,
>  emacs-devel@gnu.org
> Date: Mon, 01 Jul 2024 18:24:20 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I do not mean calling malloc. I mean, what happens if a signal arrives
> >> _while_ malloc is still in the process of allocating data?
> >
> > That's what I mean by "you mean malloc".
> >
> > If a signal happens while malloc is in progress, it is not a problem,
> > because signal handlers should not re-enter malloc.
> 
> So, maybe it is going to be enough to make sure that we block signals
> while running `alloc_impl' (in igc.c)?

Something like that.  I'm not familiar enough with the MPS functions
we call in igc.c, but blocking signals should be done around any calls
that could take the arena lock.

> > And if that doesn't answer your question, maybe I don't understand
> > what is it exactly that you are asking.
> 
> I was mostly asking about technical implementation details of how malloc
> is preventing signals from being handled while it is doing its
> job.

It doesn't.  It's the responsibility of the signal handlers not to
re-enter malloc.

We cannot do the same with MPS, because MPS can kick in outside of our
control -- for example, if accessing some Lisp object hits the
barrier.  So we have no idea when MPS will take the arena lock, and
this cannot prevent recursive locks, except by preventing our code
which touches Lisp data from running when MPS is active because we
called it.

To say this in different words: MPS must be in control of all the
threads which can touch the data it manages, and code that runs from a
signal handler is a kind-of separate thread, except that we have no
way of registering such a thread with MPS as we do with real threads.