[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIGPROF + SIGCHLD and igc
From: |
Gerd Möllmann |
Subject: |
Re: SIGPROF + SIGCHLD and igc |
Date: |
Fri, 27 Dec 2024 09:55:57 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Helmut Eller <eller.helmut@gmail.com> writes:
> On Tue, Dec 24 2024, Gerd Möllmann wrote:
>
>>> I've looked at SIGPROF. From an admittedly brief look at this, I'd
>>> summarize my results as:
>>>
>>> - The important part is get_backtrace. The rest could be done elsewhere
>>> by posting that to a message board, or whatever the mechanism is at
>>> the end.
>
> I have an idea how to make a safer profiler. First, remember that MPS
> will stop mutator threads to protect its own consistency. What happens
> if we make the profiler its own thread? MPS will stop the profiler like
> normal mutator threads. This is useful and is as it should be.
That sounds interesting.
> The problem now is how the profiler thread can do what get_backtrace
> does. We can use a protocol between the profiler thread and the main
> thread that goes like this:
>
> 1. The profiler periodically sends a signal, say SIGPROF, to the main
> thread.
>
> 2. In the signal handler for SIGPROF, the main thread synchronizes
> itself with the profiler by communicating over a pipe (like the Unix
> fathers did it). It sends some token to the profiler and waits.
>
> 3. The profiler receives the token and can now access the virtual
> machine state because the main thread waits. The profiler now does
> what get_backtrace does. After logging the stack snapshot, the
> profiler sends the token back to the main thread
>
> 4. The main thread receives the token, returns from the signal handler,
> and continues execution.
>
> Note that the signal handler only communicates over the pipe and doesn't
> read or write any memory that could mess up MPS. The profiler thread
> doesn't run any signal handlers (other than those that MPS may use
> behind the scenes).
I think I've seen a pipe being used in similar circumstances elsewhere,
not in Emacs, in an actor system handling signals. Very interesting. I
like it.
> Another observation: MPS sends SIGXFSZ and SIGXCPU to stop and resume
> threads. We could intercept those signals and block SIGPROF while the
> thread is stopped. Obviously a hack, but could still be useful.
Do you know if it does the same on macOS? It sounds like something the
Mach heritage of macOS might kick in.
>
> Helmut
- Re: SIGPROF + SIGCHLD and igc, (continued)
- 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, 2024/12/29
- 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 <=
- 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
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/28