From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Gerd Moellmann Newsgroups: gmane.emacs.devel Subject: Re: signal handling bogosities Date: Thu, 19 Dec 2002 09:04:25 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20021219140425.GB28566@gnu.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1040306690 2410 80.91.224.249 (19 Dec 2002 14:04:50 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 19 Dec 2002 14:04:50 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18P1I6-0000cT-00 for ; Thu, 19 Dec 2002 15:04:46 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18P1JG-0008QL-00 for ; Thu, 19 Dec 2002 15:05:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18P1ID-0005zh-06 for emacs-devel@quimby.gnus.org; Thu, 19 Dec 2002 09:04:53 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18P1Hu-0005kY-00 for emacs-devel@gnu.org; Thu, 19 Dec 2002 09:04:34 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18P1Hm-0005Ns-00 for emacs-devel@gnu.org; Thu, 19 Dec 2002 09:04:30 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18P1Hl-0005MJ-00 for emacs-devel@gnu.org; Thu, 19 Dec 2002 09:04:25 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.10) id 18P1Hl-0007WL-00 for emacs-devel@gnu.org; Thu, 19 Dec 2002 09:04:25 -0500 Original-To: emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:10282 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10282 Miles Bader writes: > Eli suggested that you might be a good person to ask about the > following problem (I presume you're not subscribed to emacs-devel). Hi Miles. No, I'm not reading emacs-devel. [...] > Basically the problem seem to be that it's evaluating lisp code in a > place where it shouldn't, though I'm not sure I understand all the rules > for exactly where is OK and where is not. The rule is pretty simple: one must not modify the state of the Lisp interpreter while handling a signal because the Lisp interpreter isn't reentrant. [...] > Now, I suppose that calling the lisp interpreter inside a signal handler > might be a bad thing, and so perhaps the check in Feval is reasonable > (though the byte-code evaluator _doesn't_ seem to check; perhaps if I > compiled my code, it would work :-). I don't think so :). The Lisp interpreter doesn't protect itself against signals, that is, the signal might have interrupted the interpreter at an arbitrary point. It's very dangerous to change anything from a signal handler that the Lisp interpreter itself might be working on in the normal thread of execution. The fact that handling_signal is only checked in one place is just because I didn't want to slow down things. IIRC, there wasn't any such check before I added one which meant that one could screw up Emacs without even noticing. > What concerns me is that even without that, it seems to be doing an > absurd amount of stuff inside the the signal handler, to the extent that > it seems very hard to be sure _what_ code will end being called. Well said. > After it does the face lookup that killed me, it seems to go and > actually display the mouse face, and in other branches of the code > the whole redisplay engine seems to be invoked, for exposure events > (I don't know whether that can result in lisp code being called, but > it seems as if it could -- given the complexity of redisplay, it's > kind of hard to tell). The code in xterm.c carefully avoids modifying that state of the Lisp interpreter asynchronously (or let's say it did when I resigned; I don't know what it does now), but you're absolutely right that it's hard to see it does that without studying the code in detail. > So what do people think? The whole thing seems really broken to me, but > I don't have a complete grasp of the code. How hard would be to > restructure things to just queue this stuff for an event-loop outside > the signal handler to handle? I felt this way of doing X from a signal handler is broken ever since I started to write the new redisplay and studied that part of the code in Emacs 19. And there's not just the problem that Lisp can't be called from the signal handling code, it also goes the other way 'round. Normal code can be interrupted at any time by a signal, so anything used in xterm.c had better be in a consistent state when the signal is processed; that's the reason why regions of code in xfaces.c, for example, protect themselves against signals. And to add to that, some Xt functionality (specifically timeouts) is tightly coupled to having an Xt event loop. That's why widgets using timeouts, like some scroll bar and menu widgets, don't work well with Emacs, or don't work without jumping through hoops. BTW, XEmacs developers told me it is using a normal event loop instead of the signal abomination. My feeling is that the cost of restructuring the code to use an event loop could be pretty high, but I've never investigated this very deeply because Richard thought the current way of doing things is good, and an event loop is an abomination :). There were lots of other things to do anyway, so I didn't pursue this further. Specifically for mouse-highlighting there may be a cheaper solution, though. IIRC, I once talked with Stefan Monnier about generating mouse-highlight input events for mouse highlights instead of doing the display directly when handling the mouse movement event (analogous to help-echo, for example). When that is done, normal redisplay could be used to draw the mouse-highlight, but it would have to be extended to use mouse-face for part of the text, which it currently doesn't. Also, the logic determining which parts of a buffer/window are to be redisplayed would have to be extended somehow so that the highlighted region is displayed despite the fact that there have been no buffer changes.