Re: SIGPROF + SIGCHLD and igc

[Eli Zaretskii <eliz@gnu.org>]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,  Eli
>  Zaretskii <eliz@gnu.org>,
>   ofv@wanadoo.es,  emacs-devel@gnu.org,  acorallo@gnu.org
> Date: Sat, 28 Dec 2024 11:02:44 +0100
> 
> On Fri, Dec 27 2024, Helmut Eller wrote:
> 
> > Pip Cet via wrote:
> >> ...forever, if the profiler thread has been suspended at this point.
> >
> > Hmm.  Indeed.  So back to the drawing board.
> 
> It seems that the statement
> 
>   block SIGPROF while MPS holds the lock
> 
> is logically equivalent to
> 
>   deliver SIGPROF only while MPS does not hold the lock.

Not necessarily.  Blocking a signals delays its delivery until the
time the signal is unblocked.  By contrast, what you propose will be
unable to profile code which caused MPS to take the lock.

> This variant might be bit easier to implement.  The "while MPS does not
> hold the lock" part can be implemented by claiming the lock in the
> profiler thread like so:
> 
>   mps_arena_t arena = global_igc->arena;
>   ArenaEnter (arena);
>   ... deliver SIGPROF part goes here ...
>   ArenaLeave (arena);

What happens if, when we call ArenaEnter, MPS already holds the arena
lock?

> The functions ArenaEnter and ArenaLeave are not part of the public API
> but they are external symbols, so the linker can find them.

We should ask the MPS folks what they think about using non-public
API.

> The "deliver SIGPROF" part goes like this:
> 
> 1. The profiler thread calls pthread_kill (SIGPROF, <main_thread>) and
>    then waits (on a pipe or whatever).
> 
> 2. The SIGPROF handler gets called and immediately notifies the profiler
>    thread (without waiting for a reply).  After that, it continues as
>    usual calling get_backtrace etc.
> 
> 3. The profiler thread awakes and releases the lock.

This leaves a small window between the time the SIGPROF handler writes
to the pipe and the time the profiler thread calls ArenaLeave.  During
that window, the arena is locked, AFAIU, and we can still have
recursive-lock situations, which cause an abort.  Am I missing
something?

> Regarding deadlocks: the profiler thread holds the lock while it waits.
> So MPS should not be able to stop the profiler thread there.

Which means we don't register the profiler thread with MPS, right?