Re: igc, macOS avoiding signals

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

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>> On Tue, Dec 31 2024, Eli Zaretskii wrote:
>>> We'd need to add a new function to process_pending_signals, which
>>> would process SIGPROF and maybe also SIGALRM.  The signal handlers for
>>> those would then only set a flag (not pending_signals, some other
>>> flag).
>>
>> I implemented this with the two attached patches.  The trouble is that,
>> the recorded backtraces are not same.  This can be seen by looking at
>> the call tree produced by profiler.el and the attached profiler-test.el.
>> When add_sample is called in the signal handler, then the call tree for
>> the foo example looks so:
>>
>>     ...
>>     1986 100%         main
>>     1986 100%           record-samples
>>     1986 100%             foo
>>     1074  54%               float-time
>>        0   0%   ...
>>
>> When add_sample is called from process_pending_signals, it looks like
>> this:
>>
>>     ...
>>     1986 100%         main
>>     1986 100%           record-samples
>>     1986 100%             foo
>>        0   0%   ...
>>
>> Not the absence of float-time.  The reason for this is, that in
>> bytecode.c, maybe_quit is called before the function is pushed to the
>> backtrace with record_in_backtrace.  In the second patch, I moved this
>> call forward to before the function is popped with lisp_eval_depth--.
>> With this patch, the call tree includes float-time again:
>>
>>     ...
>>     1989 100%         main
>>     1989 100%           record-samples
>>     1989 100%             foo
>>     1981  99%               float-time
>>        0   0%   ...
>>
>> However, float-time has now 99% as opposed to 54% in the first call
>> tree.
>>
>> A more complex pair of call trees is attached in the files
>> bar-0.report and bar-2.report.  A significant difference there is
>> in this section:
>>
>>      ...
>>      781  73%                     animate-place-char
>>       19   1%                       delete-char
>>       16   1%                       floor
>>        4   0%                       undo-auto--undoable-change
>>        4   0%                         undo-auto--boundary-ensure-timer
>>       96   9%                       insert-char
>>       14   1%                         undo-auto--undoable-change
>>        6   0%                           undo-auto--boundary-ensure-timer
>>        5   0%                       beginning-of-line
>>      232  21%                       move-to-column
>>      ...
>>
>> compared to the version with both patches applied:
>>
>>      ...
>>      693  72%                     animate-place-char
>>       32   3%                       delete-char
>>       29   3%                       window-start
>>       43   4%                       insert-char
>>      309  32%                       move-to-column
>>      222  23%                       beginning-of-line
>>        8   0%                       undo-auto--undoable-change
>>        8   0%                         undo-auto--boundary-ensure-timer
>>        8   0%                           run-at-time
>>        8   0%                             timer-set-function
>>        8   0%                               timerp
>>        8   0%                                 vectorp
>>      ...
>>
>> E.g. the percentage attributed to beginning-of-line is quite different
>> in those two versions (23% and 0%).
>>
>> I'm not sure if those differences are acceptable.  I also have no good
>> idea how to reduce it, except inserting more calls to maybe_quit.
>>
>> (In eval_sub and Ffuncall, it would also help the profiler to move the
>> maybe_quit call forward before lisp_eval_depth--. This would only matter
>> for interpreted functions, not in byte compiled code.  Curiously,
>> apply_lambda doesn't call maybe_quit at all.)
>>
>> Helmut
>
> Doesn't matter much at this point, probably, but I'm feeling a bit
> uneasy about the pending_profiler_signals count.
>
> Say we get two SIGPROFs that we can't record samples for, for some
> reason. The signals occur at times t0 and t1. We then add_sample(2) at
> t2 > t1 with the assumption that sample(t1) is close to sample(t2) so to
> speak, which I find okay if t2 is close enough to t1.
>
> When we use a count of 2 though, we kind of also assumes that sample(t0)
> is close to samole(t1).
>
> Is that okay? Not sure.

Another thought that crossed my mind. Not that I have an idea
how to use that, but maybe someone else has?

With the existing arrangement, a count in the profiler log means time.
It's count * sampling-interval since SIGPROFs arrive in fixed
intervals, ignoring details.

With the new arrangement, the intervals between samples are generally
not fixed length. Sampling is done when we get to it. Of course when
we get to it often enough, we are approximating fixed intervals, but
in general a count doesn't necessarily measure time, or only to a
degree.

Can we use that somehow?