Re: MPS: profiler

[Gerd Möllmann]

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

> On Fri, Jun 21 2024, Gerd Möllmann wrote:
>
>> I'm still not sure. What I'm trying to say is that we need to be sure
>> that there are no windows left in which things can change. I'd be most
>> comfortable ATM if the first thing the SIGPROF handler does is check
>> is_busy and immediately returns, doing nothing.
>
> Let's assume for moment that SIGPROF and SIGSEGV are handled in the same
> thread.  Then either SIGPROF comes before SIGSEGV or after.
>
> Case 1 (SEGPROF before SIGSEGV): here mps_arena_busy will return false
> and will access the MPS-managed memory.  This is fine, because to MPS
> this is no different than any other client code.

That would be SIGPROF delivered while client has not hit a barrier
before. SIGPROF handler runs and may hit a barrier or not.

If it doesn't hit a barrier, that's a good case, I think.

If the SIGPROF handler does hit a barrier, MPS handles the SIGSEGV
resulting from it, presumably, and let's say it takes some time.

If no SIGPROF arrives during that time, we are in case 2 (SIGSEGV before
SIFPROF). If a SIGPROF arrives kind of also.

> Case 2 (SEGSEGV before SIGPROF): here mps_arena_busy will return true
> and we only increase a counter.  This is also fine.
>
> Convinced this is safe and that we that have covered all cases?

Hmmmmmmm, I guess it wouldn't hurt to try, so I've pushed your patch :-)