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 Message-ID: <19970921092855.07004@lemis.com> In-Reply-To: <199709201345.XAA26010@godzilla.zeta.org.au>; from Bruce Evans on Sat, Sep 20, 1997 at 11:45:16PM %2B1000 References: <199709201345.XAA26010@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970921092855.07004>