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#12327: Signal-handler cleanup for Emacs Date: Sun, 02 Sep 2012 12:01:11 -0700 Organization: UCLA Computer Science Department Message-ID: <5043ACF7.7080100@cs.ucla.edu> References: <50428E57.8070708@cs.ucla.edu> <83d324fh3c.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 1346612502 22843 80.91.229.3 (2 Sep 2012 19:01:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Sep 2012 19:01:42 +0000 (UTC) Cc: lekktu@gmail.com, 12327@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 02 21:01:43 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 1T8FQT-0002MU-PX for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Sep 2012 21:01:42 +0200 Original-Received: from localhost ([::1]:50982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8FQR-0000Kv-0s for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Sep 2012 15:01:39 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8FQO-0000Km-2n for bug-gnu-emacs@gnu.org; Sun, 02 Sep 2012 15:01:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8FQN-0003RP-25 for bug-gnu-emacs@gnu.org; Sun, 02 Sep 2012 15:01:36 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8FQM-0003RL-VE for bug-gnu-emacs@gnu.org; Sun, 02 Sep 2012 15:01:34 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T8FRm-00036M-Bm for bug-gnu-emacs@gnu.org; Sun, 02 Sep 2012 15:03: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: Sun, 02 Sep 2012 19:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12327 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 12327-submit@debbugs.gnu.org id=B12327.134661256211886 (code B ref 12327); Sun, 02 Sep 2012 19:03:02 +0000 Original-Received: (at 12327) by debbugs.gnu.org; 2 Sep 2012 19:02:42 +0000 Original-Received: from localhost ([127.0.0.1]:34831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T8FRS-00035f-Bt for submit@debbugs.gnu.org; Sun, 02 Sep 2012 15:02:42 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:34244) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T8FRP-00035U-I3 for 12327@debbugs.gnu.org; Sun, 02 Sep 2012 15:02:41 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 8F7E439E8008; Sun, 2 Sep 2012 12:01:10 -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 URK2R25QQYcl; Sun, 2 Sep 2012 12:01:10 -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 23B2539E8007; Sun, 2 Sep 2012 12:01:10 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 In-Reply-To: <83d324fh3c.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:63686 Archived-At: On 09/02/2012 10:51 AM, Eli Zaretskii wrote: > that doesn't impede code reading and understanding in any way Sure it does, because Emacs defines symbols incompatibly with their normal meanings. E.g., Emacs redefines 'sigblock' to be a macro whose type signature is incompatible with the 'sigblock' that is found on GNU/Linux. This sort of thing makes Emacs's signal-handling code more confusing than it needs to be, and is the main motivation for the patch. > I could go with replacing 'signal' etc. with their modern Posix > replacements, such as 'sigaction', directly in the code. That would make the mainline code significantly less readable. Instead of this, for example: unblock_signal (SIGPIPE); send_process_trap would have to do something like this: sigset_t mask; ... sigemptyset (&mask); sigaddset (&mask, SIGPIPE); pthread_sigmask (SIG_UNBLOCK, &mask, NULL); which is not an improvement. I suspect the main reason that Emacs currently uses macros reminiscent but incompatible with the obsolete 4.2BSD interface, rather than the standard POSIX interface, is because the 4.2BSD interface was simpler. Unfortunately, the 4.2BSD interface does not scale well to modern systems with lots of signals. > I fail to see any good reasons for changes that, e.g., hide a > pair of calls to well-known library functions, such as 'sigemptyset' > and 'sigaddset', behind 'sigsetmask' (which AFAIK is a BSD-ism) There must be some confusion here. The new code does not use sigsetmask. > As for 0.6% reduction in the size of .text: what kind of humongous > .text size do you have that makes 0.6% a significant value? Every little bit helps, no? But the main point of measuring text size is as a rough gauge of the efficiency implications. If the text segment had grown, that would have been a bad sign. The fact that it shrank is a good sign. Fewer instructions mean faster CPU performance, partly due to lower pressure on the instruction cache. I didn't bother to measure CPU performance earlier, since that takes more work, but I just now did that with an artificial benchmark that simply blocks and then unblocks SIGCHLD, and on my platform the proposed patch speeds up this benchmark by 15%.