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 12:32:15 +0300 Message-ID: <83k3vvtyw0.fsf@gnu.org> References: <50543449.1070306@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1347701589 18652 80.91.229.3 (15 Sep 2012 09:33:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Sep 2012 09:33:09 +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 11:33:12 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 1TCokQ-0000nJ-7t for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Sep 2012 11:33:10 +0200 Original-Received: from localhost ([::1]:50237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCokM-00058x-64 for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Sep 2012 05:33:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCokJ-00058k-2U for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 05:33:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCokH-0003ro-Gf for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 05:33:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCokH-0003ri-CF for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 05:33:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TColG-000772-97 for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 05:34:03 -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 09:34: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.134770160727297 (code B ref -1); Sat, 15 Sep 2012 09:34:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 15 Sep 2012 09:33:27 +0000 Original-Received: from localhost ([127.0.0.1]:34735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCokf-00076C-0J for submit@debbugs.gnu.org; Sat, 15 Sep 2012 05:33:25 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55073) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCokb-000762-Vh for submit@debbugs.gnu.org; Sat, 15 Sep 2012 05:33:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCoja-0003ZV-LB for submit@debbugs.gnu.org; Sat, 15 Sep 2012 05:32:19 -0400 Original-Received: from lists.gnu.org ([208.118.235.17]:59802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCoja-0003ZR-IN for submit@debbugs.gnu.org; Sat, 15 Sep 2012 05:32:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44644) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCojZ-00055v-Eq for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 05:32:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCojX-0003Wg-JG for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 05:32:17 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:42912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCojX-0003TL-By for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 05:32:15 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MAD00M00X0LKN00@a-mtaout22.012.net.il> for bug-gnu-emacs@gnu.org; Sat, 15 Sep 2012 12:32:14 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAD00LI6X5PN8G0@a-mtaout22.012.net.il>; Sat, 15 Sep 2012 12:32:14 +0300 (IDT) In-reply-to: <50543449.1070306@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:64342 Archived-At: > Date: Sat, 15 Sep 2012 00:54:49 -0700 > From: Paul Eggert > CC: Eli Zaretskii , Juanma Barranquero > > When auditing signal-handling in preparation for cleaning it up, I > found that configuring --without-sync-input has race conditions that > look like they would be a real pain to fix. Many of these involve > memory allocation within a signal handler, which is tricky and > dangerous. Emacs attempts to work around the problems, but these > workarounds are not sufficient and fixing them would not be easy. > [...] > void * > xmalloc (size_t size) > { > - void *val; > - > - MALLOC_BLOCK_INPUT; > - val = malloc (size); > - MALLOC_UNBLOCK_INPUT; > - > + void *val = malloc (size); > if (!val && size) > memory_full (size); > return val; Calling xmalloc was always safe to invoke from asynchronous entry into the display engine, which happens, e.g., when mouse events are processed. Your patch removes that line of defense, which makes me very nervous. At the very least, let's have BLOCK_INPUT around the call to malloc (and similarly in the other related functions). > I see that nt/config.nt has "#undef SYNC_INPUT" but do the Microsoft > ports care one way or another whether SYNC_INPUT is set? If so, why? I cannot answer that question, because the full semantics of SYNC_INPUT is unclear to me. All I can say now is that input events on MS-Windows come from a separate thread that runs asynchronously to the main thread (the latter runs the Lisp interpreter and all the other parts of Emacs). So, at least up front, Emacs on MS-Windows does use non-SYNC_INPUT input method, if SYNC_INPUT is to be understood literally. OTOH, it could be that no one bothered or dared to define SYNC_INPUT on MS-Windows when that method became the default on Posix platforms. (The fact that config.nt undefines SYNC_INPUT is not indicative of anything except that autogen/config.in does the same; the fact that ms-w32.h does _not_ define SYNC_INPUT is the important detail.) If someone can describe in detail what SYNC_INPUT means, what it assumes of the target platform, and how is that reflected in the logic of the related code, then I could try investigating the meaning of it for the MS-Windows build. As we no longer have on board people who really understand the Emacs event handling on MS-Windows, such an investigation will take a lot of time and effort, diverting my scarce time from general-purpose Emacs development (such as menus on TTYs and the remaining bits of bidi), and will necessarily be error-prone. So I'd really like to be sure there are very good reasons for removing the non-SYNC_INPUT code. It could be that a better alternative is to leave that code alone, if only by replacing the conditionals with WINDOWSNT or some such. Btw, it looks like the NS port also uses the !SYNC_INPUT code; your changes seem to remove that code without any substitute. Btw2, your changes remove code conditioned on #if defined SYNC_INPUT || defined USABLE_SIGIO but do not remove code conditioned on USABLE_SIGIO alone. Is that TRT? > Since it's an undocumented and deprecated configure-time option, and > has been that way for over four years, and the non-SYNC_INPUT code is > a real mess that is getting in the way of improving Emacs, now seems > like a good time to remove that code. In what ways does the current SYNC_INPUT code get in the way of improving Emacs, and what kinds of improvement will significantly benefit from the proposed changes? 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 for us to leave it alone and concentrate our energy on adding new user-level features. Really, the latest push on non-trivial low-level changes seems to me like a drain on our resources, with little real gains, except perhaps on some obscure platforms I never heard about or in even more obscure use-cases. The only real effect of this is a significant destabilization of the development codebase, which people already starting to complain about. I could understand such loss of stability when the goal is a significant improvement in some important feature, like GC or the display engine. But having that for the sake of some mythical "ease of improving Emacs" sounds like a net loss to me. It reminds me of the sorry state of roads in my country, which are permanently in a state of being "maintained for future improvements", causing closure of some of the lanes and generally making the traffic more jammed than it needs to be. In general, Emacs has long ago reached the state where low-level code is stable and should be left alone, with most of the maintenance effort directed towards adding user-level features. Low-level code changes should be considered only when there are very good reasons for them. Am I the only one who thinks so?