[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?
- Re: SIGPROF + SIGCHLD and igc, (continued)
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/24
- Re: SIGPROF + SIGCHLD and igc, Gerd Möllmann, 2024/12/24
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Pip Cet, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/29
- Re: SIGPROF + SIGCHLD and igc,
Eli Zaretskii <=
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/29
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/29
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/29
- Re: SIGPROF + SIGCHLD and igc, Gerd Möllmann, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Gerd Möllmann, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Pip Cet, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/28