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 03:14:50 -0700 Organization: UCLA Computer Science Department Message-ID: <5054551A.1070207@cs.ucla.edu> References: <50543449.1070306@cs.ucla.edu> <83k3vvtyw0.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 1347704108 3647 80.91.229.3 (15 Sep 2012 10:15:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Sep 2012 10:15:08 +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 12:15:11 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 1TCpP5-0005cC-7c for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Sep 2012 12:15:11 +0200 Original-Received: from localhost ([::1]:58217 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCpP1-00069b-5K for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Sep 2012 06:15:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCpOx-00064y-CU for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 06:15:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCpOu-000150-0k for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 06:15:02 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCpOt-00014v-Tl for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 06:14:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TCpPt-000876-Vt for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 06:16:02 -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 10:16:01 +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.134770415931180 (code B ref -1); Sat, 15 Sep 2012 10:16:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 15 Sep 2012 10:15:59 +0000 Original-Received: from localhost ([127.0.0.1]:34845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCpPr-00086r-CX for submit@debbugs.gnu.org; Sat, 15 Sep 2012 06:15:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38928) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCpPo-00086i-AD for submit@debbugs.gnu.org; Sat, 15 Sep 2012 06:15:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCpOm-00013M-MU for submit@debbugs.gnu.org; Sat, 15 Sep 2012 06:14:53 -0400 Original-Received: from lists.gnu.org ([208.118.235.17]:39494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCpOm-00013E-J8 for submit@debbugs.gnu.org; Sat, 15 Sep 2012 06:14:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCpOl-00061U-Ha for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 06:14:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCpOj-00012S-2T for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 06:14:51 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:39672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCpOi-00012B-QI; Sat, 15 Sep 2012 06:14:48 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 4E5C339E800D; Sat, 15 Sep 2012 03:14:48 -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 rTXtq5R75Of1; Sat, 15 Sep 2012 03:14:47 -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 A49A939E8008; Sat, 15 Sep 2012 03:14:47 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 In-Reply-To: <83k3vvtyw0.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:64351 Archived-At: 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.... > 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. 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. 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. The non-SYNC_INPUT code is the worst part of that mess. If we can remove it it'd be a real win. Even if we can disable it everywhere but on Microsoft platforms, it'd still be a win. > 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. > let's have BLOCK_INPUT around the call to malloc (and similarly in > the other related functions). That can be left in for the Windows case if needed. But it shouldn't be needed on non-Windows platforms. > It could be that a better alternative is to leave that code alone, > if only by replacing the conditionals with WINDOWSNT or some such. Yes, that's an alternative. That way, I could still skip the non-SYNC_INPUT code when auditing signal-handling on POSIXish platforms. But it'd be nicer if we could just remove that code. > it looks like the NS port also uses the !SYNC_INPUT code Sorry, I don't see why. 'configure --with-ns' does not disable SYNC_INPUT. > Btw2, your changes remove code conditioned on > > #if defined SYNC_INPUT || defined USABLE_SIGIO No, actually, the changes kept that code. They merely removed the condition (as it's now always true). > but do not remove code conditioned on USABLE_SIGIO alone. Is that > TRT? Yes, that sounds right. USABLE_SIGIO merely means that SIGIO is usable and SIGIO signals can be handled. That's not the same thing as SYNC_INPUT. > In what ways does the current SYNC_INPUT code get in the way of > improving Emacs, The SYNC_INPUT code is not the problem. It's the non-SYNC_INPUT code that's dicey. Generally speaking signal handlers have to be very disciplined and simple about what they do -- there's only a small number of function calls that are portable in signal handlers. The non-SYNC_INPUT code's signal handlers pretty much do whatever they want, which leads to races. > 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. It should be doable for the SYNC_INPUT case. (I'm just talking about POSIXish platforms here; I don't know about Windows.)