Re: SIGPROF + SIGCHLD and igc

[Eli Zaretskii]

> Date: Sat, 28 Dec 2024 20:43:18 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gerd.moellmann@gmail.com, ofv@wanadoo.es, 
> emacs-devel@gnu.org, acorallo@gnu.org
> 
> "Helmut Eller" <eller.helmut@gmail.com> writes:
> 
> > On Sat, Dec 28 2024, Pip Cet wrote:
> >
> >>> I think I see what you mean.  I imagine the profiler thread to be a loop
> >>> like
> >>>
> >>>   while (true) {
> >>>      sleep (<x-seconds>)
> >>>      ArenaEnter (<arena>)
> >>>        pthread_kill (SIGPROF, <main-thread>)
> >>>        wait (<pipe>)
> >>>      ArenaLeave (<arena>)
> >>>   }
> >>
> >> I'm not really following.  Did you mean to include a call to a "clear
> >> all memory barriers" function after the ArenaEnter call?  If not, the
> >> SIGPROF handler (and all handlers interrupting the SIGPROF handler which
> >> aren't being delayed) would not be able to access MPS memory, which I
> >> thought was the goal.
> >
> > In my mind it works like this: when the SIGPROF handler tries to access
> > MPS memory, the SIGSEGV handler kicks in as it usually would in a
> > non-signal handler context.  This should work because at the beginning
> > of the SIGPROF handler we guarantee that MPS doesn't hold the arena
> > lock.
> 
> Sorry, still not following.  The SIGPROF-sending thread holds the arena
> lock.  So we can't take it in the SIGSEGV handler.  It's still a
> deadlock, right?

But the SIGPROF handler doesn't take the arena lock, it starts by
writing to the pipe, which then causes the SIGPROF-sending thread to
release the lock, thus letting the SIGPROF handler touch memory which
could trigger MPS into taking the lock.