[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12471: Avoid some signal-handling races, and simplify.
From: |
Eli Zaretskii |
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@cs.ucla.edu>
> CC: 12471@debbugs.gnu.org, lekktu@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.
- bug#12471: Avoid some signal-handling races, and simplify., (continued)
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/20
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/21
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/21
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/21
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/21
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/21
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/21
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/21
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify.,
Eli Zaretskii <=
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Stefan Monnier, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/22
bug#12471: Avoid some signal-handling races, and simplify., Jan Djärv, 2012/09/19