emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: igc, macOS avoiding signals


From: Gerd Möllmann
Subject: Re: igc, macOS avoiding signals
Date: Mon, 30 Dec 2024 20:55:57 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Helmut Eller <eller.helmut@gmail.com>,  pipcet@protonmail.com,
>>   spd@toadstyle.org,  emacs-devel@gnu.org
>> Date: Mon, 30 Dec 2024 19:37:38 +0100
>> 
>> So, to summarize, everyone agrees with Helmut? 
>
> That the SIGPROF handler in the form he described would be safe?  I
> agree.

What we have in scratch/igc:

static void
handle_profiler_signal (int signal)
{
  EMACS_INT count = 1;
#if defined HAVE_ITIMERSPEC && defined HAVE_TIMER_GETOVERRUN
  if (profiler_timer_ok)
    {
      int overruns = timer_getoverrun (profiler_timer);
      eassert (overruns >= 0);
      count += overruns;
    }
#endif
  add_sample (&cpu, count);
}

static void
add_sample (struct profiler_log *plog, EMACS_INT count)
{
#ifdef HAVE_MPS
  if (igc_busy_p ())
#else
  if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */
#endif
    /* Special case the time-count inside GC because the hash-table
       code is not prepared to be used while the GC is running.
       More specifically it uses ASIZE at many places where it does
       not expect the ARRAY_MARK_FLAG to be set.  We could try and
       harden the hash-table code, but it doesn't seem worth the
       effort.  */
    plog->gc_count = saturated_add (plog->gc_count, count);
  else
    record_backtrace (plog, count);
}

bool
igc_busy_p (void)
{
  return mps_arena_busy (global_igc->arena);
}

Now the question is if that's what Helmut was describing.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]