Re: igc, macOS avoiding signals

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Pip Cet <pipcet@protonmail.com> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>> "Helmut Eller" <eller.helmut@gmail.com> writes:
>>>> I find that difficult to understand. But it may be just a
>>>> statistical phenomenon. Maybe filling up an APs memory is so fast so
>>>> that the probability of a signal hitting while owning the mutex is close
>>>> to zero, or something.
>>>
>>> Very few of Emacs' signal handlers actually touch a barrier.  I've also
>>
>> Indeed.  These crashes are rare in typical usage, which doesn't mean we
>> should delay fixing them until Emacs is "unstable enough".  It already
>> is, IMHO, because we take that approach too frequently.
>>
>>> not seen any reproducable receipes for the "signal issues" that the igc
>>> branch supposedly has.
>>
>> Removing the SIGPROF protection code should allow Ihor's recipe to crash
>> again.
>
> Confirmed.  Here's the recipe (which, yes, you have already seen):
>
> https://lists.gnu.org/archive/html/emacs-devel/2024-06/msg00560.html
>
> Make igc_busy_p () return false (as we could do if the "supposed" signal
> issue weren't real), immediate crash.
>
> Pip

With

  modified   src/profiler.c
  @@ -347,7 +347,7 @@ record_backtrace (struct profiler_log *plog, EMACS_INT count)
   add_sample (struct profiler_log *plog, EMACS_INT count)
   {
   #ifdef HAVE_MPS
  -  if (igc_busy_p ())
  +  if (false)
   #else
     if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */
   #endif

Result:

        1083  89% + command-execute
         106   8% + redisplay_internal (C function)
          13   1% + timer-event-handler
           1   0% + help--append-keystrokes-help
           1   0% + #<byte-code-function A81>
           0   0%   ...

🤷