Re: SIGPROF + SIGCHLD and igc

[Helmut Eller]

On Sat, Dec 28 2024, Eli Zaretskii wrote:

>> It seems that the statement
>> 
>>   block SIGPROF while MPS holds the lock
>> 
>> is logically equivalent to
>> 
>>   deliver SIGPROF only while MPS does not hold the lock.
>
> Not necessarily.  Blocking a signals delays its delivery until the
> time the signal is unblocked.  By contrast, what you propose will be
> unable to profile code which caused MPS to take the lock.

Hmm, I think I disagree.  But I'm not sure of what sequence of events
you're thinking of.

>> This variant might be bit easier to implement.  The "while MPS does not
>> hold the lock" part can be implemented by claiming the lock in the
>> profiler thread like so:
>> 
>>   mps_arena_t arena = global_igc->arena;
>>   ArenaEnter (arena);
>>   ... deliver SIGPROF part goes here ...
>>   ArenaLeave (arena);
>
> What happens if, when we call ArenaEnter, MPS already holds the arena
> lock?

Since MPS holds the lock, it would run in a different thread.  So the
profiler thread blocks until MPS releases the lock.

ArenaEnter uses non-recursive locks.

>> The "deliver SIGPROF" part goes like this:
>> 
>> 1. The profiler thread calls pthread_kill (SIGPROF, <main_thread>) and
>>    then waits (on a pipe or whatever).
>> 
>> 2. The SIGPROF handler gets called and immediately notifies the profiler
>>    thread (without waiting for a reply).  After that, it continues as
>>    usual calling get_backtrace etc.
>> 
>> 3. The profiler thread awakes and releases the lock.
>
> This leaves a small window between the time the SIGPROF handler writes
> to the pipe and the time the profiler thread calls ArenaLeave.  During
> that window, the arena is locked, AFAIU, and we can still have
> recursive-lock situations, which cause an abort.  Am I missing
> something?

During that time window, the lock is held by the profiler thread.  The
SIGPROF handler runs in the main thread.  If the main thread tries to
claim the lock, it will block until the profiler thread releases it.

>> Regarding deadlocks: the profiler thread holds the lock while it waits.
>> So MPS should not be able to stop the profiler thread there.
>
> Which means we don't register the profiler thread with MPS, right?

I'm not sure. It may not be safe to call ArenaEnter in non-registered
threads.

Helmut