From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 12471@debbugs.gnu.org, lekktu@gmail.com
Subject: bug#12471: Avoid some signal-handling races, and simplify.
Date: Sat, 22 Sep 2012 11:02:18 +0300 [thread overview]
Message-ID: <83obkywkmt.fsf@gnu.org> (raw)
In-Reply-To: <505CC70B.6050308@cs.ucla.edu>
> 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.
next prev parent reply other threads:[~2012-09-22 8:02 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-18 23:39 bug#12471: Avoid some signal-handling races, and simplify Paul Eggert
2012-09-19 16:18 ` Eli Zaretskii
2012-09-20 6:07 ` Paul Eggert
2012-09-20 17:44 ` Eli Zaretskii
2012-09-21 7:42 ` Paul Eggert
2012-09-21 8:31 ` Eli Zaretskii
2012-09-21 17:26 ` Paul Eggert
2012-09-21 17:38 ` Eli Zaretskii
2012-09-21 18:13 ` Paul Eggert
2012-09-21 18:27 ` Eli Zaretskii
2012-09-21 19:59 ` Paul Eggert
2012-09-22 8:02 ` Eli Zaretskii [this message]
2012-09-22 8:47 ` Paul Eggert
2012-09-22 9:10 ` Eli Zaretskii
2012-09-22 9:40 ` Paul Eggert
2012-09-22 10:07 ` Eli Zaretskii
2012-09-22 10:55 ` Paul Eggert
2012-09-22 11:16 ` Eli Zaretskii
2012-09-22 20:28 ` Stefan Monnier
2012-09-22 21:55 ` Paul Eggert
2012-09-23 3:55 ` Eli Zaretskii
2012-09-23 3:52 ` Eli Zaretskii
2012-09-19 16:45 ` Jan Djärv
2012-09-19 19:58 ` Paul Eggert
2012-09-20 6:27 ` Jan Djärv
2012-09-19 21:36 ` Andy Moreton
2012-09-23 9:36 ` bug#12471: installed into trunk Paul Eggert
2012-09-23 15:22 ` Andy Moreton
2012-09-23 16:23 ` Andy Moreton
2012-09-23 17:37 ` Juanma Barranquero
2012-09-23 17:37 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83obkywkmt.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=12471@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=lekktu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.