GNU bug report logs - #12327
Signal-handler cleanup for Emacs

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 12327 <at> debbugs.gnu.org
Subject: bug#12327: Signal-handler cleanup for Emacs
Date: Sun, 02 Sep 2012 12:01:11 -0700

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%.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.