From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Calling Lisp from undo.c's record_* functions Date: Thu, 19 Nov 2015 17:53:34 +0200 Message-ID: <83poz67zpd.fsf@gnu.org> References: <83r3jpc2of.fsf@gnu.org> <87h9kkbz6k.fsf@russet.org.uk> <838u5wbmvu.fsf@gnu.org> <83ziyc9zs0.fsf@gnu.org> <83wptg9dcd.fsf@gnu.org> <87610zsd3u.fsf@russet.org.uk> <83io4z9ozx.fsf@gnu.org> <87wpte8fas.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447948471 31942 80.91.229.3 (19 Nov 2015 15:54:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 15:54:31 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord), Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 19 16:54:19 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZzRXL-0003wa-4d for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 16:54:15 +0100 Original-Received: from localhost ([::1]:42590 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRXK-0002OU-Ks for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 10:54:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRX1-0002Ml-PQ for emacs-devel@gnu.org; Thu, 19 Nov 2015 10:54:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzRWx-0001et-Kh for emacs-devel@gnu.org; Thu, 19 Nov 2015 10:53:55 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:37310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRWx-0001eD-CA; Thu, 19 Nov 2015 10:53:51 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NY200000JT1TE00@a-mtaout22.012.net.il>; Thu, 19 Nov 2015 17:53:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY2000J8K5PO040@a-mtaout22.012.net.il>; Thu, 19 Nov 2015 17:53:49 +0200 (IST) In-reply-to: <87wpte8fas.fsf@russet.org.uk> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194792 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: , > 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.