bug#12471: Avoid some signal-handling races, and simplify.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 21 Sep 2012 00:42:45 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12471@debbugs.gnu.org, lekktu@gmail.com
> 
> > On Windows, 'kill' is redefined to call 'emacs_abort', when its
> > first arg is Emacs's own PID and the second arg is SIGABRT.
> 
> For consistency, how about if Windows also defines 'raise' to call
> 'emacs_abort', when the signal is SIGABRT?  That should fix the
> problem, and it shouldn't require any change to the mainline code.  It
> could be something as simple as this in a Windows-specific include
> file, perhaps:
> 
> 	#define raise(sig) kill (getpid (), sig)

I don't want to do that.  I guess I'd special-case WINDOWSNT then, if
we cannot do better.

> > Can we do better than that?  Ideally, there should be a single
> > function, the signal handler, which does everything.
> 
> I tried that initially but the code was bulkier and more error-prone.
> Each handler needed to have an extra local variable (to save errno)
> and to call two auxiliary-library functions, one for setup and the
> other for teardown.  In contrast, the proposed approach requires no
> additional locals and one auxiliary-library function.  It's true that
> it requires two functions for each per-process signal, one for the
> thread catching the signal and one for the main process, but I find
> that actually simpler, since it makes it clearer which handler code is
> run where.

To me, the code looks overly complicated.  By the time you get to the
meat, you have already done 2 or 3 hops, which makes tracing
processing of a specific signal unduly complex.