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

[Eli Zaretskii]

> Date: Sat, 22 Sep 2012 03:55:13 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12471@debbugs.gnu.org, lekktu@gmail.com
> 
> On 09/22/2012 03:07 AM, Eli Zaretskii wrote:
> 
> > 'sys_kill' does not do what's expected from 'raise', far from it.
> 
> It may not do what's expected for 'raise' for arbitrary Windows
> applications, yes.  But it doesn't need to do that.  All that's
> needed is what Emacs expects for 'raise'.

'sys_kill' doesn't support what Emacs expects from 'raise', except for
SIGABRT.  Please read the code, it's quite self-explanatory.

> > 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.
> 
> But the proposed patch does not replace the existing 'raise'.

It does, as far as Emacs code is concerned.

> > 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
> 
> The current trunk is already invoking sys_kill with all those signals.
> If this behavior isn't correct for Windows, it needs to be fixed,
> regardless of whether the proposed patch is applied.  The proposed
> patch doesn't make this problem any worse, or any better.

Yes, it does, in that it enters 'raise' into this messy picture.