Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: gerd.moellmann@gmail.com,  pipcet@protonmail.com,  yantar92@posteo.net,
>   emacs-devel@gnu.org
> Date: Sun, 30 Jun 2024 12:24:58 +0200
> 
> On Sun, Jun 30 2024, Eli Zaretskii wrote:
> 
> > 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.

What arguments are those?  SIGCHLD doesn't tell us the PID of the
process (or any other data that could be used to identify the
process), AFAICT.  What if two or more sub-processes exited while we
are in MPS-land?

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

I'm not talking about the queue, I'm talking about accessing the data
which needs to be put on the queue.  The deferred job must be
accompanied with enough meta-data to identify what happened, otherwise
the deferred handler will not know how to do the job.

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

What do you mean by "scanner"?  I was talking about our signal
handlers.  If they qualify as "scanner", please explain why.

Anyway, if a signal handler cannot do anything useful, the only
alternative is to block select signals around code which could violate
those restrictions.