Re: SIGPROF + SIGCHLD and igc

[Helmut Eller <eller.helmut@gmail.com>]

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.

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).

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.

Helmut