Re: MPS: a random backtrace while toying with gdb

[Helmut Eller <eller.helmut@gmail.com>]

On Sun, Jun 30 2024, Eli Zaretskii wrote:

>> I would move most of the work out of signal handlers.  The signal
>> handler could put the work in a "async work queue" and then return.  The
>> actual work is then processed by maybe_quit.
>
> But in this case we hit the barrier just by accessing the process
> object.  How can you do anything useful in a SIGCHLD handler if you
> cannot even find out which process exited and how did it exit?

You don't do anything useful other than packing up the arguments that
the signal handler receives and put them in the queue.

> Surely, something like that is needed in order to put any work on some
> queue?  And I'm not even talking about the effects of deferring this
> job "for later" on the speed of working with sub-processes in Emacs.

The queue is not in MPS-managed memory; so we can access it.

> IMO, we must find a way of touching MPS-managed memory safely from a
> signal handler, otherwise writing signal handlers will become an
> impossible job.

The MPS documentation says quite clearly that a scanner must not access
MPS-managed memory other than the block it receives as argument:

  https://memory-pool-system.readthedocs.io/en/latest/topic/format.html#cautions

5. Format methods must not:

   a. call library code;
   b. access MPS-managed memory in pools that protect their contents;
   c. perform a non-local exit (for example, by throwing an exception, or
      calling longjmp());
   d. call any functions or macros in the MPS other than
      MPS_SCAN_BEGIN, MPS_SCAN_END, MPS_FIX1(), MPS_FIX12(), MPS_FIX2(), and
      MPS_FIX_CALL.

   It’s permissible to call other functions in the client program, but
   see MPS_FIX_CALL for a restriction on passing the scan state.

6. Subject to the above constraints, format methods can freely access:

   a. memory inside the object or block that they have been asked to
      look at;
   b. MPS-managed memory in pools that do not protect their contents;
   c. memory not managed by the MPS.