Re: MPS: a random backtrace while toying with gdb

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Not a crime, but we are using a lib that we know uses barriers and
>> functions of which get invoked when we hit such a barrier. We can't just
>> ignore that.
>
> 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.

> 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.

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