Re: MPS: a random backtrace while toying with gdb

[Pip Cet <pipcet@protonmail.com>]

On Sunday, June 30th, 2024 at 18:42, Helmut Eller <eller.helmut@gmail.com> wrote:
> On Sun, Jun 30 2024, Eli Zaretskii wrote:
> 
> > > 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?
> 
> This patch below implements the idea I was thinking about.

I don't think it's sufficiently careful about modifying C structures from signal handlers, though. The signal can occur between any two CPU instructions, and that opens up (rare, but possible) race conditions. IIUC the consensus is you can set an "int" or "bool" to true, or write to a self-pipe, but that's about as much as you should ever do in a signal handler...

As Eli points out, most of our signals don't have arguments, so how about simply having one flag per signal? Even a global signal flag would require us to block signals while we clear it.

Pip