Re: SIGPROF + SIGCHLD and igc

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

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