bug#12327: Signal-handler cleanup for Emacs

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 01 Sep 2012 15:38:15 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, Juanma Barranquero <lekktu@gmail.com>
> 
> Here's a patch to clean up Emacs's signal-handling code somewhat.
> As described below, it shrinks the size of Emacs's text segment
> by 0.6% on my platform.  It also removes a few dozen lines from
> the source code.

FWIW, I cannot see any advantage in these changes.  They just replace
one system of macros by another.  The advantage of the current code is
that it invokes widely known standard APIs, such as 'signal',
'sigemptyset', and 'sigblock' (never mind that we redefine some of
them to call their more modern equivalents: that doesn't impede code
reading and understanding in any way).  OTOH, the changes you propose
replace that with APIs that AFAIK are not known to anyone and, with a
couple of exceptions, not used anywhere else.

I could go with replacing 'signal' etc. with their modern Posix
replacements, such as 'sigaction', directly in the code.  That will
clean up old APIs while still maintaining clarity for anyone who has
ever written signal handlers.  But 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), or behind newly-invented functions such as
'get_sigmask_block_signal'.

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?  On 2
different platforms to which I have access, one of them a x86_64
GNU/Linux, I see ~3.5MB in an unoptimized build and about half that
much in an optimized one, which makes the savings around 2KB, too
small to justify any change whatsoever.  What am I missing?