emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SIGPROF + SIGCHLD and igc


From: Eli Zaretskii
Subject: Re: SIGPROF + SIGCHLD and igc
Date: Sun, 29 Dec 2024 21:05:24 +0200

> 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 19:50:09 +0100
> 
> On Fri, Dec 27 2024, Eli Zaretskii wrote:
> [...]
> > You are basically describing the way SIGPROF emulation is implemented
> > on Windows (see w32proc.c for the details).  But I don't understand
> > why you need that pipe: doesn't pthreads allow one thread to stop the
> > other?  If so, just make the "profiler thread" stop the main thread
> > instead of your step 2, and resume the main thread instead of your
> > step 4.  Am I missing something?
> 
> 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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]