GNU bug report logs - #12471
Avoid some signal-handling races, and simplify.

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12471 <at> debbugs.gnu.org, lekktu <at> gmail.com
Subject: bug#12471: Avoid some signal-handling races, and simplify.
Date: Sat, 22 Sep 2012 12:10:04 +0300

> Date: Sat, 22 Sep 2012 01:47:47 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 12471 <at> debbugs.gnu.org, lekktu <at> gmail.com
> 
> On 09/22/2012 01:02 AM, Eli Zaretskii wrote:
> 
> > What you suggest now is that I add to 'sys_kill' a lot of stuff for it to
> > be able to replace 'raise'
> 
> Sorry, I don't follow.  I did not suggest that, at any rate.
> 
> Currently, emacs.c does the equivalent of this:
> 
>   kill (getpid (), sig);
> 
> which on Windows is macro-expanded to
> 
>   sys_kill (_getpid (), sig);
> 
> The proposed patch causes Emacs to do the
> same Windows actions via the redefined 'raise'.  That is,
> emacs.c will do 'raise (sig)', and the implementation
> of 'raise (sig)' will do 'sys_kill (_getpid (), sig)'.

Which means 'sys_kill' will need to do everything that's expected from
'raise'.  Like I wrote:

> because a replacement of a library function needs to be at least as
> good as the function it replaces.

> If there is a problem with the proposed patch with respect
> to Emacs sending a signal to itself, why doesn't the
> current Emacs trunk have the same problem?

I already explained that, too:

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

> And if so, shouldn't that problem be addressed independently,
> regardless of the patch proposed for Bug#12471?

It will be, once the dust settles on this (or we enter the feature
freeze, whichever comes first).  I was asking not to aggravate the
situation, if it's possible.

> > I will always prefer a small burden to a larger one.
> 
> I was referring to the overall burden, for all maintainers,
> not just the burden for the Windows maintainers in particular.

So was I.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.