Date: Tue, 28 Apr 1998 14:31:14 -0500 From: Karl Denninger <karl@mcs.net> To: Jason Nordwick <nordwick@scam.XCF.Berkeley.EDU> Cc: dyson@FreeBSD.ORG, Robert Withrow <witr@rwwa.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER Message-ID: <19980428143114.33662@mcs.net> In-Reply-To: <19980428192742.1224.qmail@xcf.berkeley.edu>; from Jason Nordwick on Tue, Apr 28, 1998 at 07:27:42PM -0000 References: <199804280030.UAA06099@spooky.rwwa.com> <199804280453.XAA03316@dyson.iquest.net> <19980428073841.05698@mcs.net> <19980428192742.1224.qmail@xcf.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 28, 1998 at 07:27:42PM -0000, Jason Nordwick wrote: > > Karl Denninger, on Tue 4/28/1998, wrote the following: > > > > SIGDANGER is useful if properly trapped and handled. I'd like to see if > > supported with the default to be "ignore" (ie: you have to ASK for it to > > be delivered and processed). > > > > Then it would almost always be ignored? Wouldn't this reqire patching > almost every noncritical program? It would probably be easier just to > patch a few important tools and find a Good(c) way to pick the > unlucky process. > > jay No, you patch the critical ones to do something useful with the trap. The ignored ones are known to the kernel, and they are subject to getting whacked without notice (just like we have now). Critical programs can either free up resources or exit, as they see fit. We could also define a semantic that says that if a process set SIGHOLD for that signal, then the kernel should do everything in its power NOT to whack that particular process. This leaves you with: 1) Do nothing - you get the semantics we have now. If the kernel needs to whack you it will, without notice, but the warning is ignored (you don't want to do anything with it). 2) Trap the signal - you get notice, and can clean up and exit if you are able. You're still vulnerable, in that the kernel can whack you if it needs to (and you're still around). The kernel can put these processes into the "second round" bucket - it at least knows that you're trying to help. 3) Set SIG_HOLD. You're a critical process and the kernel should go pick on someone else if it can. If it can't, well, tough bananas, but at least we tried to keep you going. This preserves the EXISTING way things work if the programmer does nothing at all. The problem with AIX is that the default, that is, "do nothing", results in you getting killed when you might not really be killed (ie: the kernel is low on space but not completely out of resources). This also leads to three "buckets" - the "default" ones, which get nailed first, the "I'm trying to be nice" ones, which get nailed next, and the "oh shit the system is fucked if these die" ones, which are the kills of last resort. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980428143114.33662>