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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 22 Sep 2012 02:40:41 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12471@debbugs.gnu.org, lekktu@gmail.com
> 
> On 09/22/2012 02:10 AM, Eli Zaretskii wrote:
> > Which means 'sys_kill' will need to do everything that's expected from
> > 'raise'. 
> 
> Unless I'm missing something, the only thing that Emacs will
> expect from 'raise' is that it act like 'sys_kill' on itself,
> so the proposed patch shouldn't affect what 'sys_kill' needs
> to do.

'sys_kill' currently supports only SIGABRT when called for the Emacs
process itself.  E.g., it will happily ignore SIGSEGV or SIGILL, and
when passed SIGTRAP, it will try to kill some subprocess.  It's quite
apparent from the code and from the comments that in its current shape
'sys_kill' does not do what's expected from 'raise', far from it.

> I'm perhaps stating the obvious here, but just in case
> I'm misunderstanding please bear with me: the Windows
> substitutes for kill, raise, etc. need not support every
> POSIX feature.  They need to support only the features that
> Emacs uses.  So sys_raise need not support every feature that
> POSIX requires for 'raise'; it needs to support only the
> 'raise' features that Emacs uses.  Likewise for 'sys_kill'
> versus POSIX 'kill'.

This is true for APIs, like 'kill', that don't exist in the library.
Those can be extended one feature at a time, because the missing
features don't work anyway.

But for existing library functions, the only sane way to replace them
is to have the replacement support all the features supported by the
function being replaced.  Otherwise, one would need to analyze every
possible call to the function, both directly and indirectly, in order
to understand what needs and what needs not be supported; that
analysis needs to be done for every change in related code, to reveal
the new features that need to be supported.

And even if we want to support "only" the features you had in mind,
'sys_kill' will need to be extended to support all the fatal signals
that wind up in 'fatal_error_backtrace'/'terminate_due_to_signal' or
whatever it is called these days.  All that in order to call a single
function anyway.  I don't want to do it.