unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: phillip.lord@russet.org.uk (Phillip Lord),
	Richard Stallman <rms@gnu.org>
Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
Subject: Re: Calling Lisp from undo.c's record_* functions
Date: Thu, 19 Nov 2015 17:53:34 +0200	[thread overview]
Message-ID: <83poz67zpd.fsf@gnu.org> (raw)
In-Reply-To: <87wpte8fas.fsf@russet.org.uk>

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: <monnier@IRO.UMontreal.CA>,  <emacs-devel@gnu.org>
> 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.



  reply	other threads:[~2015-11-19 15:53 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-16 16:46 Calling Lisp from undo.c's record_* functions Eli Zaretskii
2015-11-16 21:51 ` Phillip Lord
2015-11-16 22:51 ` Stefan Monnier
2015-11-17 12:14   ` Phillip Lord
2015-11-17 13:46     ` Stefan Monnier
2015-11-17 14:42       ` Phillip Lord
2015-11-17 15:40         ` Stefan Monnier
2015-11-17 16:24           ` Eli Zaretskii
2015-11-17 16:49             ` Stefan Monnier
2015-11-17 17:05               ` Eli Zaretskii
2015-11-17 17:34                 ` Stefan Monnier
2015-11-17 18:00                   ` Eli Zaretskii
2015-11-17 19:09                     ` Stefan Monnier
2015-11-17 19:22                       ` Eli Zaretskii
2015-11-17 21:05                     ` Phillip Lord
2015-11-17 21:02               ` Phillip Lord
2015-11-18  2:55                 ` Stefan Monnier
2015-11-18 12:26                   ` Phillip Lord
2015-11-17 16:35         ` Eli Zaretskii
2015-11-17 20:52           ` Phillip Lord
2015-11-18  3:38             ` Eli Zaretskii
2015-11-18  9:56               ` Phillip Lord
2015-11-18 10:49                 ` David Kastrup
2015-11-18 17:30                 ` Eli Zaretskii
2015-11-17 16:40     ` Eli Zaretskii
2015-11-17 16:51       ` Stefan Monnier
2015-11-17 19:44         ` Eli Zaretskii
2015-11-17 21:35           ` Phillip Lord
2015-11-18  2:52           ` Stefan Monnier
2015-11-18  3:49             ` Eli Zaretskii
2015-11-18 12:31               ` Phillip Lord
2015-11-18 17:49                 ` Eli Zaretskii
2015-11-19  1:49                   ` Stefan Monnier
2015-11-19 10:16                   ` Phillip Lord
2015-11-19 15:53                     ` Eli Zaretskii [this message]
2015-11-19 17:49                       ` Stefan Monnier
2015-11-19 17:58                         ` Eli Zaretskii
2015-11-19 18:17                           ` Stefan Monnier
2015-11-22 21:44                       ` Phillip Lord
2015-11-22 22:41                         ` John Wiegley
2015-11-23 17:29                           ` Phillip Lord
2015-11-23  3:37                         ` Eli Zaretskii
2015-11-23 17:28                           ` Phillip Lord
2015-11-25 17:43                             ` Eli Zaretskii
2015-11-25 22:51                               ` Richard Stallman
2015-11-26 10:27                               ` Phillip Lord
2015-11-17 21:13       ` Phillip Lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83poz67zpd.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=phillip.lord@russet.org.uk \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).