From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#12450: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 12:59:44 -0700 Organization: UCLA Computer Science Department Message-ID: <5054DE30.1020806@cs.ucla.edu> References: <50543449.1070306@cs.ucla.edu> <83k3vvtyw0.fsf@gnu.org> <5054551A.1070207@cs.ucla.edu> <837grvtuo5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1347739213 29229 80.91.229.3 (15 Sep 2012 20:00:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Sep 2012 20:00:13 +0000 (UTC) Cc: lekktu@gmail.com, 12450@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 15 22:00:15 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1TCyXH-0007Oe-45 for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Sep 2012 22:00:15 +0200 Original-Received: from localhost ([::1]:38535 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCyXD-00038j-67 for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Sep 2012 16:00:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCyX6-00033l-5W for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 16:00:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCyX2-000589-Mf for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 16:00:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCyX2-000585-Im for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 16:00:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TCyY2-0000vW-Df for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 16:01:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 Sep 2012 20:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12450 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12450-submit@debbugs.gnu.org id=B12450.13477392593554 (code B ref 12450); Sat, 15 Sep 2012 20:01:02 +0000 Original-Received: (at 12450) by debbugs.gnu.org; 15 Sep 2012 20:00:59 +0000 Original-Received: from localhost ([127.0.0.1]:35805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCyXz-0000vG-5B for submit@debbugs.gnu.org; Sat, 15 Sep 2012 16:00:59 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:49514) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCyXv-0000v8-KZ for 12450@debbugs.gnu.org; Sat, 15 Sep 2012 16:00:57 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 24C3D39E8015; Sat, 15 Sep 2012 12:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H16IhSsike2B; Sat, 15 Sep 2012 12:59:48 -0700 (PDT) Original-Received: from [192.168.1.3] (pool-108-23-119-2.lsanca.fios.verizon.net [108.23.119.2]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id A550239E8014; Sat, 15 Sep 2012 12:59:48 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 In-Reply-To: <837grvtuo5.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:64371 Archived-At: On 09/15/2012 04:03 AM, Eli Zaretskii wrote: >> But [BLOCK_INPUT around malloc calls] shouldn't be needed on >> non-Windows platforms. > > Are we absolutely sure? Can we prove that malloc is never called by > async code? Yes. We know where our signal handlers are, and we can audit them to make sure they can't call non-async-signal-safe code. And that's the way Emacs has been running for years, on GNU and POSIXish platforms: it has not been putting BLOCK_INPUT around malloc calls. On these platforms this patch is nothing new -- it's simply ratifying standard practice. I'm not saying that the SYNC_INPUT code is 100% bug-free -- it's not, and that's why I'm auditing it -- but it's much, much better than the non-SYNC_INPUT code is. Out of curiosity, what happens in MS-Windows if you take the current trunk and change nt/config.nt's "#undef SYNC_INPUT" to "#define SYNC_INPUT 1"? If that works, it would help simplify the code overall. >>> If someone can describe in detail what SYNC_INPUT means >> >> Sorry, as far as I know, the only detailed description is the source >> code itself. Perhaps Stefan wrote up something sometime.... > > Then how do we know that the changes are correct? First, we're using SYNC_INPUT already. All non-Windows platform use SYNC_INPUT, and have done so since 2008. Second, we know that it's not safe to invoke random system functions from signal handlers. Emacs used to get away with this, sort of, but the situation has gotten worse (i.e., flakier) with time, partly due to the issue of multithreading. So there are sound software engineering reasons to go with SYNC_INPUT. See, for example, the brief discussion in . > When is it not safe? There is a small set of standard functions that signal handlers can safely call. Calling functions outside this list is unsafe because it leads to race conditions. Usually the unsafe functions work, but sometimes they don't, and bugs are hard to track down and fix. The exact list of safe functions depends on the platform. For OpenBSD, for example, there's a list in . POSIX has a standard list in . Code that limits itself to the POSIX list should be safe in practice. Emacs probably needs to go beyond the POSIX list, on a platform-by-platform basis, but it needs to take some care when doing so. > what is this about: > >> -#ifdef REL_ALLOC >> - malloc_hysteresis = 32; >> -#else >> - malloc_hysteresis = 0; >> -#endif malloc_hysteresis is used only by the non-SYNC_INPUT code. Removing the non-SYNC_INPUT code lets us remove cruft that is needed only because of the non-SYNC_INPUT code. > I never have such problems on MS-Windows I don't use MS-Windows. Apparently our experiences on GNU/Linux differ. I expect that I am a heavier use of that platform and so am more likely to run into Emacs bugs there. I'm not the only one to think that the non-SYNC_INPUT code is questionable -- it's been a longstanding issue. Since the MS-Windows port does not exercise the interrupt-based input handling defined by the non-SYNC_INPUT code, that could well explain why you're not observing problems with MS-Windows. And this would also suggest that the MS-Windows code does not care whether SYNC_INPUT is used, so it can also profitably change to use SYNC_INPUT. > With the kind of high rate of changes we see in Emacs, I've been seeing problems for years. It's not due to any recent changes. > If it works well, The non-SYNC_INPUT code doesn't work well at all. The SYNC_INPUT code is better, but it can still use an audit, which I'm doing. > whoever wants to make non-trivial changes in that code _must_ > understand it very well. I understand the non-Microsoft side well, and from that point of view this change is a good one, because it removes unused and confusing code that complicates the job of Emacs maintenance. I do not understand the Microsoft side, but that should be a separate issue. >>> it looks like the NS port also uses the !SYNC_INPUT code >> >> Sorry, I don't see why. > > Simply because there's HAVE_NS code in there. Yes, and there's non-HAVE_NS code in there too. But that's not relevant. The point is that SYNC_INPUT is always 1 for the NextStep port, just as it's always 1 for all ports other than MS-Windows.