Re: igc, macOS avoiding signals

[Gerd Möllmann]

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.