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

[Paul Eggert]

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

> 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'. so
it doesn't need to worry about supporting everything that Windows
'raise' does.  All the patch does is to tell Emacs to call
'sys_raise' where emacs.c would normally call 'raise'.  This
doesn't affect other calls to 'raise'.  The Windows 'raise'
function still exists, and will still do what it normally does
on Windows, when any non-Emacs module calls it.

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