From owner-freebsd-hackers  Sat Sep 20 17:00:10 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA03099
          for hackers-outgoing; Sat, 20 Sep 1997 17:00:10 -0700 (PDT)
Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03070;
          Sat, 20 Sep 1997 17:00:02 -0700 (PDT)
Received: (from grog@localhost)
	by freebie.lemis.com (8.8.7/8.8.5) id JAA02354;
	Sun, 21 Sep 1997 09:28:56 +0930 (CST)
Message-ID: <19970921092855.07004@lemis.com>
Date: Sun, 21 Sep 1997 09:28:55 +0930
From: Greg Lehey <grog@lemis.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com,
        hackers@FreeBSD.ORG, julian@whistle.com, mike@smith.net.au,
        phk@critter.freebsd.dk
Subject: Re: Bug in malloc/free
References: <199709201345.XAA26010@godzilla.zeta.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81e
In-Reply-To: <199709201345.XAA26010@godzilla.zeta.org.au>; from Bruce Evans on Sat, Sep 20, 1997 at 11:45:16PM +1000
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8250
Fax: +61-8-8388-8250
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Fight-Spam-Now: http://www.cauce.org
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sat, Sep 20, 1997 at 11:45:16PM +1000, Bruce Evans wrote:
>>>>	"coredump, right now, no ifs, whens or buts. Thank you."
>>>
>>> A new signal, like SIGKILL except it generates cores, would be useful.
>>> We would have to fix all the assumptions that sigset_t == int to make
>>> room for another signal number.
>>
>> Is that really so important?  You can call sigaction from a signal
>> handler, so you can unmask the signal before calling it.  A new signal
>> for the sake of a couple of lines of library code?
>
> Only broken libraries could do that, since if a signal is masked then
> something must want it masked.

If a signal is masked, it's reasonable to assume that the something
that wants it masked is also planning to continue execution.  If our
library function has decided that we want a complete, unconditional
termination of the process, then by definition it has priority.
There's really no difference between doing it this way and adding
another signal, except that the latter adds to kernel bloat.

Greg