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

Previous Next

Full log

Message #68 received at 12471 <at> debbugs.gnu.org (full text, mbox):

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: Re: Avoid some signal-handling races, and simplify.
Date: Sat, 22 Sep 2012 14:16:12 +0300

> Date: Sat, 22 Sep 2012 03:55:13 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 12471 <at> debbugs.gnu.org, lekktu <at> gmail.com
> 
> On 09/22/2012 03:07 AM, Eli Zaretskii wrote:
> 
> > 'sys_kill' does not do what's expected from 'raise', far from it.
> 
> It may not do what's expected for 'raise' for arbitrary Windows
> applications, yes.  But it doesn't need to do that.  All that's
> needed is what Emacs expects for 'raise'.

'sys_kill' doesn't support what Emacs expects from 'raise', except for
SIGABRT.  Please read the code, it's quite self-explanatory.

> > 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.
> 
> But the proposed patch does not replace the existing 'raise'.

It does, as far as Emacs code is concerned.

> > 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
> 
> The current trunk is already invoking sys_kill with all those signals.
> If this behavior isn't correct for Windows, it needs to be fixed,
> regardless of whether the proposed patch is applied.  The proposed
> patch doesn't make this problem any worse, or any better.

Yes, it does, in that it enters 'raise' into this messy picture.

Previous Next

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