Re: Elisp native profiler

[Stefan Monnier]

>> > Shouldn't profiling use the same framework as atimers
>> > and the other async events?
>> We could do that, but to the extent that it is possible to do all the
>> work in the signal_handler while still being safe, I think it's
>> preferable.
> I bet the "read input in a signal handler" started that way, too.

AFAIK, the "read input in a signal handler" has been wrong/racy from
the beginning.  Tho, I guess at the beginning either the author didn't
know it was wrong, or he figured he could avoid the known problems with
it by playing with the malloc hooks.

But, yes, maybe at some we'll have to do it differently.  But doing it
differently means:
- doing potentially more work on QUIT (thus slowing down Emacs even
  when the profiler is not in use).
- suffer from a sampling bias (only the stack traces that lead to
  a QUIT can be sampled).
- miss some samples (because no QUIT occurred between the two signals).
- running QUIT more often (to reduce the bias and try and avoid missing
  some samples), again slowing down Emacs even when the profiler is not
  in use.
So I think for now I'd rather try and stick to "do it in the handler".

  
        Stefan