Re: SIGPROF + SIGCHLD and igc

[Pip Cet]

"Helmut Eller" <eller.helmut@gmail.com> writes:

> On Sat, Dec 28 2024, Eli Zaretskii wrote:
>
>> I'm thinking about a situation where SIGPROF was delivered while it
>> was blocked.  In that case, it will be re-delivered once we unblock
>> it.
>>
>> By contrast, if we avoid delivering SIGPROF in the first place, it
>> will never be delivered until the next time SIGPROF is due.
>>
>> So imagine a function FUNC that conses some Lisp object.  This calls
>> into MPS, which blocks SIGPROF, takes the arena lock, then does its
>> thing, then releases the lock and unblocks SIGPROF.  If SIGPROF
>> happened while MPS was working with SIGPROF blocked, then the moment
>> SIGPROF is unblocked, the SIGPROF handler in the main thread will be
>> called, and will have the opportunity to see that we were executing
>> FUNC.  By contrast, if the profiler thread avoided delivering SIGPROF
>> because it saw the arena locked, the next time the profiler thread
>> decides to deliver SIGPROF, execution could have already left FUNC,
>> and thus FUNC will not be in the profile.
>>
>> I hope I made myself more clear this time.
>
> I think I see what you mean.  I imagine the profiler thread to be a loop
> like
>
>   while (true) {
>      sleep (<x-seconds>)
>      ArenaEnter (<arena>)
>        pthread_kill (SIGPROF, <main-thread>)
>        wait (<pipe>)
>      ArenaLeave (<arena>)
>   }

I'm not really following.  Did you mean to include a call to a "clear
all memory barriers" function after the ArenaEnter call?  If not, the
SIGPROF handler (and all handlers interrupting the SIGPROF handler which
aren't being delayed) would not be able to access MPS memory, which I
thought was the goal.

Pip