Re: Calling Lisp from undo.c's record_* functions

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Cc: <address@hidden>,  <address@hidden>
> Date: Thu, 19 Nov 2015 10:16:43 +0000
> 
> > Really?  IOW, an idle timer doesn't run when we have read something
> > from a subprocess, and return to the waiting loop?  I would expect the
> > idle timers to run in that situation.
> 
> You've misunderstood. Emacs idle timers run when the user is idle, not
> emacs!

The reason I expected that is that AFAIK the same loop in which Emacs
waits for input and where it determines whether it's idle is the same
loop where Emacs also checks for input from processes (and any other
kind of input that comes from file descriptors, like network or serial
traffic).  That is why I expected that input from processes and
keyboard input will be handled similarly.

> Can you test this branch for me, and see if you can reproduce the error.
> 
> fix/segfault-undoable-change-prepare-for-buffer
> 
> This leaves the implementation as was, but moves the run_undoable_change
> call to prepare_for_change_1.

I will try, but I don't see the need to delay installing these
changes, if the reason is the need to wait for me to run a bootstrap,
since I believe you've found a way to reproduce the original problem
on your system.  I do, however, want to hear one more opinion about
calling Lisp from such a low-level code.

Richard, can we please have your opinion on this?  To recap, the
original problem was that record_point, called by insert_from_string,
changed the buffer gap while insert_from_string was itself
manipulating the gap.  This happened because record_point called Lisp
which caused GC, which decided to compact the buffer.  More details
are here:

  http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01532.html

The proposed solution moves the call to Lisp to a subroutine of
prepare_to_modify_buffer.  This seems to avoid calling Lisp while the
gap is being manipulated, but my question is: are there any pitfalls
to calling Lisp code on the level of insdel.c functions?  I'd like to
hear your opinion before we decide whether to install the proposed
solution, or look for a safer one.

Thanks.