From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12450: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 14:03:22 +0300 Message-ID: <837grvtuo5.fsf@gnu.org> References: <50543449.1070306@cs.ucla.edu> <83k3vvtyw0.fsf@gnu.org> <5054551A.1070207@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1347707766 28637 80.91.229.3 (15 Sep 2012 11:16:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Sep 2012 11:16:06 +0000 (UTC) Cc: lekktu@gmail.com, 12450@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 15 13:16:09 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 1TCqM5-000493-Ai for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Sep 2012 13:16:09 +0200 Original-Received: from localhost ([::1]:33187 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCqM1-0004nr-EJ for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Sep 2012 07:16:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCqLx-0004kO-Dq for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 07:16:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCqLw-0003zd-7K for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 07:16:01 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCqLw-0003zY-4K for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 07:16:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TCqMw-0002wA-Ge for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 07:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 Sep 2012 11:17: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: X-Debbugs-Original-Cc: lekktu@gmail.com, bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.134770777511224 (code B ref -1); Sat, 15 Sep 2012 11:17:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 15 Sep 2012 11:16:15 +0000 Original-Received: from localhost ([127.0.0.1]:34966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCqMA-0002ux-Hs for submit@debbugs.gnu.org; Sat, 15 Sep 2012 07:16:14 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53425) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCqM7-0002uc-9v for submit@debbugs.gnu.org; Sat, 15 Sep 2012 07:16:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCqL3-0003Sz-DA for submit@debbugs.gnu.org; Sat, 15 Sep 2012 07:15:08 -0400 Original-Received: from lists.gnu.org ([208.118.235.17]:42538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCqL3-0003Qj-9y for submit@debbugs.gnu.org; Sat, 15 Sep 2012 07:15:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCq9l-0003rw-1o for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 07:03:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCq9j-0008Ek-5v for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 07:03:24 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:57759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCq9i-0008DR-TX for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 07:03:23 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MAE00F0019GPF00@a-mtaout23.012.net.il> for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 14:03:20 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAE00FFB1DKOG50@a-mtaout23.012.net.il>; Sat, 15 Sep 2012 14:03:20 +0300 (IDT) In-reply-to: <5054551A.1070207@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:64357 Archived-At: > Date: Sat, 15 Sep 2012 03:14:50 -0700 > From: Paul Eggert > CC: bug-gnu-emacs@gnu.org, lekktu@gmail.com > > On 09/15/2012 02:32 AM, Eli Zaretskii wrote: > > > 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? You don't just remove "#ifdef SYNC_INPUT", you also make additional changes. E.g., what is this about: > -#ifdef REL_ALLOC > - malloc_hysteresis = 32; > -#else > - malloc_hysteresis = 0; > -#endif ? If Emacs uses REL_ALLOC, won't it need this? If this is related to SYNC_INPUT, please explain how. > > I was under the impression that the low-level code to which > > SYNC_INPUT is relevant doesn't need any improvements, because it > > works well enough > > It doesn't work well enough in my experience. I often get crashes > or near-crashes with Emacs. It'll stop and ask me whether I want > it to abort and dump core, say. Or it'll just crash. I never have such problems on MS-Windows (or anywhere else where I use Emacs, including on GNU/Linux). As MS-Windows uses the non-SYNC_INPUT code, I don't see any evidence for that code being buggy, at least not on MS-Windows. > This sort of thing can be a real problem. The problem is less > common for me now than it was five years ago, and I credit > SYNC_INPUT for some of that, but it's still too unreliable. Or it could be some other, unrelated changes. With the kind of high rate of changes we see in Emacs, I don't think it's reasonable to attribute changes in stability to a single change in the sources, without a clear evidence. > One way I can help improve things is to clean up signal handling, > which is a huge pile of spaghetti at the low level -- it's so > complicated that I expect that hardly anybody understands it. If it works well, there's no need to understand it, is there? OTOH, whoever wants to make non-trivial changes in that code _must_ understand it very well. And you just said you didn't. > > Calling xmalloc was always safe to invoke from asynchronous entry into > > the display engine, which happens, e.g., when mouse events are > > processed. > > That was the intent, yes, but in the non-SYNC_INPUT case it wasn't > really safe. Why not? When is it not safe? > 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? You don't suggest that, if that assumption is false, we prefer crashing to blocking input, do you? > > 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. For example: -#if defined SYNC_INPUT || defined USABLE_SIGIO static void handle_async_input (void) { interrupt_input_pending = 0; -#ifdef SYNC_INPUT pending_signals = pending_atimers; -#endif -/* Tell ns_read_socket() it is being called asynchronously so it can avoid - doing anything dangerous. */ -#ifdef HAVE_NS <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< - ++handling_signal; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< -#endif <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< + while (1) { int nread; @@ -7199,13 +7178,8 @@ if (nread <= 0) break; } -#ifdef HAVE_NS <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< - --handling_signal; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< -#endif <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< } -#endif /* SYNC_INPUT || USABLE_SIGIO */ > > and what kinds of improvement will significantly > > benefit from the proposed changes? > > I've been trying to audit the signal handling of Emacs, to help close > race conditions. Doing this for the non-SYNC_INPUT case is so painful > that I can't imagine anybody doing it. Then don't do that. Until we have problems that can reliably be traced to that code, doing so would be a wasted effort, anyway.