Re: SIGPROF + SIGCHLD and igc

[Helmut Eller]

On Fri, Dec 27 2024, Eli Zaretskii wrote:

>> I have an idea how to make a safer profiler.  First, remember that MPS
>> will stop mutator threads to protect its own consistency.
>
> Can you spell out what are "mutator threads" in this context, so we
> all are on the same page?

The mutator threads are those that we register with
mps_thread_reg.

>> 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.
>
> AFAIU, it means the profiler will not be able to account for GC, but
> let's put this aside for a moment.

Yes.  Probably a similar issue as when SIGPROF is blocked while threads
are stopped.

>> 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.
>
> You are basically describing the way SIGPROF emulation is implemented
> on Windows (see w32proc.c for the details).

Good; then I assume that we don't need to discuss that this might
introduce too much overhead.

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

You mean there is a phtread_stop function that is similar to
SuspendThread on Windows?  I've not found anything like that; but that
doesn't mean that there isn't one.  The Linux man-pages for pthreads are
notoriously useless.

I like the pipe because it's a signal safe and thread safe communication
mechanism.  It avoids the need for mutexes or stdatomic stuff; that's
best left to wizards.

>> 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).
>
> You basically emulate blocking of SIGPROF by relying on MPS to stop
> the profiler thread when it cannot allow access to memory that could
> mess up MPS, is that right?

Exactly.

>> 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 these signals get delivered to the main thread as well?  Or only to
> mutator threads?

I've not looked too closely, but the documentation for ThreadRingSuspend
suggests that they are delivered to all threads, except for the current
thread.  So if a non-main thread triggers a GC cycle, then the main
thread would receive them too.

Helmut