Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com,  yantar92@posteo.net,  emacs-devel@gnu.org,
>   eller.helmut@gmail.com
> Date: Sun, 30 Jun 2024 13:20:30 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What alternatives do we have?  Emacs code deals with Lisp objects and
> > memory managed by MPS all over the place.  In many case, the
> > programmer doesn't necessarily know whether some data is or isn't in
> > memory managed by MPS.
> 
> We know what we do in signal handlers, don't we? We'd not call the
> existing GC for example, and we have to be awware that GC mark bits ay
> be set. It's not that this is a problem all over the place in Emacs,
> outside of signal handlers.

Reality check: please re-read the code of our signal handlers to see
what they really do.

> > You are asking to do the impossible, IMO.  Refraining from touching
> > MPS-managed memory from signal handlers is simply not practical in
> > Emacs.  E.g., it would make the profiler useless, because the minimum
> > you must do from the signal handler is to see which Lisp function is
> > being run; if you defer this for later, you will see a completely
> > skewed profile.
> 
> The profiler is a special case that is true, but we could get away with
> doing something special here: detecting, with igc_busy, that we
> shouldn't do anything with Lisp atm, and instead do whatever goes.

The profiler is not a special case in any way.  The other signals I
mentioned represent similar issues.  And what about SIGUSR1/SIGUSR2?
And SIGALRM, which is used for atimers (that are the basis for
hourglass cursor)?  Heck, in TTY mode C-g triggers SIGINT, and we
process the key from the signal handler!

> If you insist on making MPS usuable in signal handlers, please go ahead
> of course.

I can't, I have too much stuff on my plate.  And implying that any
disagreement must mean go code it by yourself is at least unfair.

If you are unwilling to try what I suggest, I guess the future will
tell who is right and who isn't.  My fear is that going your way will
mean we'd need to disable many useful Emacs features or make them much
less useful.