Re: SIGPROF + SIGCHLD and igc

[Eli Zaretskii <eliz@gnu.org>]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: gerd.moellmann@gmail.com,  pipcet@protonmail.com,  ofv@wanadoo.es,
>   emacs-devel@gnu.org,  acorallo@gnu.org
> Date: Sun, 29 Dec 2024 20:34:11 +0100
> 
> On Sun, Dec 29 2024, Eli Zaretskii wrote:
> 
> >> Here another observation: Let's assume that we can emulate SuspendThread
> >> and ResumeThread on POSIX and MacOS (much like MPS does it).  In the
> >> profiler thread we can then simply do:
> >> 
> >>    SuspendThread (<main-thread>)
> >>    get_backtrace ()
> >>    ResumeThread (<main-thread>)
> >> 
> >> without invoking any SIGPROF handler or the need for
> >> ArenaEnter/ArenaLeave.
> >
> > Yes, we can.  But that means changing what the SIGPROF handler does
> > will have no effect, which is bad for maintenance.  By contrast, the
> > current MS-Windows implementation does basically the same, but it
> > calls the handler, not its body.
> >
> > Also, I don't quite see why you thing calling get_backtrace directly
> > will have any effect on the need to lock the arena.  I'm probably
> > missing something.
> 
> Ok. The arena lock is a problem.  Is that also a problem for the Windows
> implementation?  How does it avoid deadlocks when the thread holds the
> arena lock?

You mean, when the SIGPROF handler is called by the thread which
simulates the SIGPROF signal?  The handler is called in the context of
the signaling thread, not in the context of the (suspended) Lisp
thread.

> >> The only complication seems to be, that we must avoid deadlocks when MPS
> >> tries to suspend a thread is already suspended by our emulation.
> >
> > If MPS always runs from the main thread, it doesn't (and cannot)
> > suspend the thread.  Or maybe I misunderstand which thread do you mean
> > here?
> 
> I may interpret "MPS runs in a thread" differently than you do.  Maybe I
> should say a "thread is inside MPS" whenever a thread holds the arena
> lock.  With this meaning, every thread can be inside MPS.

Suspending a suspended thread on Windows doesn't cause any problems
(unless you do that more than 127 times without resuming the thread),
it just increments the thread's suspend count.  To resume, you need to
call ResumeThread that many times.

Does that answer your question?