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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 21 Sep 2012 12:59:07 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12471@debbugs.gnu.org, lekktu@gmail.com
> 
> On 09/21/2012 11:27 AM, Eli Zaretskii wrote:>> +#define raise   sys_raise
> > I already told that I don't want to do that.
> 
> Yes, but the most-recent patch did something else than what you had
> objected to, and should avoid its problems.

What I object to is replacing existing library functions when that can
be avoided.  If the most-recent patch allows avoiding that, please
tell how and where.

> > Shadowing library functions is a maintenance burden in the long run.
> 
> It's a maintenance burden no matter how we do it.

I will always prefer a small burden to a larger one.

> When it's easy, as is the case here, it's better to address
> Windows-specific problems in the Windows code.  This relieves the
> mainline maintainers of the maintenance burden of reading Windows
> code, and that is a win.

It's a win for you, but it isn't a win in general.  And anyway, I
don't understand why you take the liberty of removing me and Juanma
from the list of "mainline maintainers".  May I suggest that you
review the commit logs and look up our names?  On my part, I can tell
that there would have been a few more entries there, if it were not
for the constant flux of low-level changes lately that need constant
attention to keep the Windows port in working condition.  How do you
enter that into the "win" equation?

> Besides, this particular patch has almost no burden on the Windows
> side.  We're talking about six simple lines that fit nicely into an
> already-existing framework for this sort of thing.

No, it does not fit in the existing framework.  The existing framework
is to replace library functions and APIs that do not exist on Windows,
or are severely limited compared to the expectations of the Emacs
application code.  This isn't the case here: 'raise' has no known
problems on Windows, when called with signals it supports (SIGABRT is
one of them).

Please note that 'sys_kill' was written to emulate delivery of fatal
signals to Emacs subprocesses, not to the Emacs process.  Adding the
two lines there to support aborting Emacs was already too far-fetched;
I did that as a temporary measure of getting a sane behavior while
waiting for the dust to settle -- as I was certain (and now proved
right) that the changes done then are not the last word on this.  What
you suggest now is that I add to 'sys_kill' a lot of stuff for it to
be able to replace 'raise', and then maintain that stuff for whatever
changes will be done (and I'm sure they will) in this area, because a
replacement of a library function needs to be at least as good as the
function it replaces.  _That_ is the maintenance burden I want to
avoid.  If you can compare it with a couple of #ifdef's and still
claim with a straight face that it's a lesser evil, then we will just
have to agree to disagree.