From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#30182: Update Date: Sat, 03 Feb 2018 12:29:17 +0200 Message-ID: <83efm2bc3m.fsf@gnu.org> References: <87k1wdqc4q.fsf@gmail.com> <5A634E53.7010205@gmx.at> <87mv182bzk.fsf@gmail.com> <83a7x7sww6.fsf@gnu.org> <87efmj27d5.fsf@gmail.com> <83vafvqjbf.fsf@gnu.org> <87inbvxdz8.fsf@gmail.com> <5A65AB97.1030401@gmx.at> <87po62kk10.fsf@gmail.com> <831sih23rh.fsf@gnu.org> <5A663490.3050409@gmx.at> <87r2qh5lya.fsf@gmail.com> <5A6C37A7.2020309@gmx.at> <87r2qag5wp.fsf@gmail.com> <5A6D8947.5010207@gmx.at> <87d11t9ria.fsf@gmail.com> <5A6EF1A2.30904@gmx.at> <83lgggirzp.fsf@gnu.org> <5A702D36.6040302@gmx.at> <83po5rh3pu.fsf@gnu.org> <5A718CFA.2080408@gmx.at> <878tcdtpbk.fsf@gmail.com> <5A72DD44.3060104@gmx.at> <83lggceh9m.fsf@gnu.org> <5A742122.3090008@gmx.at> <831si3crf2.fsf@gnu.org> <5A757AFD.5040404@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1517653700 19683 195.159.176.226 (3 Feb 2018 10:28:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Feb 2018 10:28:20 +0000 (UTC) Cc: m.sujith@gmail.com, 30182@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 03 11:28:15 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ehv3J-0004ON-Ai for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Feb 2018 11:28:09 +0100 Original-Received: from localhost ([::1]:38732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehv5I-0007GZ-Pe for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Feb 2018 05:30:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehv5C-0007Fx-Dx for bug-gnu-emacs@gnu.org; Sat, 03 Feb 2018 05:30:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehv59-0002aL-3S for bug-gnu-emacs@gnu.org; Sat, 03 Feb 2018 05:30:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47045) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ehv58-0002ZJ-Vl for bug-gnu-emacs@gnu.org; Sat, 03 Feb 2018 05:30:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ehv58-00048X-Mi for bug-gnu-emacs@gnu.org; Sat, 03 Feb 2018 05:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Feb 2018 10:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30182 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30182-submit@debbugs.gnu.org id=B30182.151765378415856 (code B ref 30182); Sat, 03 Feb 2018 10:30:02 +0000 Original-Received: (at 30182) by debbugs.gnu.org; 3 Feb 2018 10:29:44 +0000 Original-Received: from localhost ([127.0.0.1]:54942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ehv4p-00047g-JM for submit@debbugs.gnu.org; Sat, 03 Feb 2018 05:29:43 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57999) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ehv4n-00047T-TY for 30182@debbugs.gnu.org; Sat, 03 Feb 2018 05:29:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehv4f-0001rx-BW for 30182@debbugs.gnu.org; Sat, 03 Feb 2018 05:29:36 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39410) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehv4f-0001rk-7b; Sat, 03 Feb 2018 05:29:33 -0500 Original-Received: from [176.228.60.248] (port=4779 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ehv4d-00066q-FO; Sat, 03 Feb 2018 05:29:32 -0500 In-reply-to: <5A757AFD.5040404@gmx.at> (message from martin rudalics on Sat, 03 Feb 2018 10:03:57 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:142842 Archived-At: > Date: Sat, 03 Feb 2018 10:03:57 +0100 > From: martin rudalics > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > > We _cannot_ call Lisp asynchronously in any safe > > way. I'm afraid we will have to roll back the change which allowed > > mode-line-default-help-echo to be a function. Can you find an > > alternative way of achieving the same effect, that doesn't call Lisp > > from note_mode_line_or_margin_highlight? > > I could do that easily. But IMO the problem is not with calling Lisp > per se. We frequently call Lisp fnctions from C. The problem is with > altering the global state (`timer-list' being part of that) IIUC. > > > I think we should introduce some protection against making such > > implementation mistakes in the future. Like some flag that we set > > when redisplay is entered asynchronously, and that is checked in > > safe__call, where we'd signal an error (or maybe even abort, under > > "--enable-checking") if the flag is set. This should allow us to find > > such problems much faster. WDYT? > > I'd need to see the problem identified first. The comment in xdisp.c > says that > > Under window systems > like X, some portions of the redisplay code are also called > asynchronously during mouse movement or expose events. It is very > important that these code parts do NOT use the C library (malloc, > free) because many C libraries under Unix are not reentrant. They > may also NOT call functions of the Lisp interpreter which could > change the interpreter's state. > > What is an "asynchronous call" and how can I identify it? That commentary was outdated. I updated it now. Please take a look and tell if anything there needs clarification or any other change. I believe that what I wrote in the message to which you were replying was based on incorrect interpretation of what actually happens. With the correct interpretation, there's no asynchronous entry into redisplay, if "asynchronous" is interpreted literally. So the measures I described above are unnecessary, but there is a need to block input around C fragments that cannot tolerate changes in global state. This now raises the question: should we block input around the 2 calls to Fcopy_sequence in timer_check, on the emacs-26 branch? I tend to think we should, because letting arbitrary Lisp change the timer lists while Fcopy_sequence runs could cause hard-to-debug bugs. WDYT? > And one thing that is obviously needed is some guidance on what should > be allowed in the mode line and what should be avoided. For example, > having `mode-line-buffer-identification' install a timer is something > that should be avoided IMO. If we protect Fcopy_sequence as indicated above, I think such a limitation would no longer be necessary. Thanks.