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 13:07:52 +0300 [thread overview]
Message-ID: <83mx0il69z.fsf@gnu.org> (raw)
In-Reply-To: <505D8799.8030905@cs.ucla.edu>
> Date: Sat, 22 Sep 2012 02:40:41 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12471@debbugs.gnu.org, lekktu@gmail.com
>
> On 09/22/2012 02:10 AM, Eli Zaretskii wrote:
> > Which means 'sys_kill' will need to do everything that's expected from
> > 'raise'.
>
> Unless I'm missing something, the only thing that Emacs will
> expect from 'raise' is that it act like 'sys_kill' on itself,
> so the proposed patch shouldn't affect what 'sys_kill' needs
> to do.
'sys_kill' currently supports only SIGABRT when called for the Emacs
process itself. E.g., it will happily ignore SIGSEGV or SIGILL, and
when passed SIGTRAP, it will try to kill some subprocess. It's quite
apparent from the code and from the comments that in its current shape
'sys_kill' does not do what's expected from 'raise', far from it.
> I'm perhaps stating the obvious here, but just in case
> I'm misunderstanding please bear with me: the Windows
> substitutes for kill, raise, etc. need not support every
> POSIX feature. They need to support only the features that
> Emacs uses. So sys_raise need not support every feature that
> POSIX requires for 'raise'; it needs to support only the
> 'raise' features that Emacs uses. Likewise for 'sys_kill'
> versus POSIX 'kill'.
This is true for APIs, like 'kill', that don't exist in the library.
Those can be extended one feature at a time, because the missing
features don't work anyway.
But 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. Otherwise, one would need to analyze every
possible call to the function, both directly and indirectly, in order
to understand what needs and what needs not be supported; that
analysis needs to be done for every change in related code, to reveal
the new features that need to be supported.
And 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
that wind up in 'fatal_error_backtrace'/'terminate_due_to_signal' or
whatever it is called these days. All that in order to call a single
function anyway. I don't want to do it.
next prev parent reply other threads:[~2012-09-22 10:07 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
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 [this message]
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=83mx0il69z.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.