From owner-freebsd-hackers Mon Apr 27 20:33:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA25782 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 20:33:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA25752 for ; Mon, 27 Apr 1998 20:33:02 -0700 (PDT) (envelope-from atf3r@cs.virginia.edu) Received: from ares.cs.virginia.edu by mail.virginia.edu id aa05594; 27 Apr 98 23:32 EDT Received: from mamba.cs.Virginia.EDU (mamba-fo.cs.Virginia.EDU [128.143.136.18]) by ares.cs.Virginia.EDU (8.8.5/8.8.5) with ESMTP id XAA19138; Mon, 27 Apr 1998 23:32:56 -0400 (EDT) Received: from localhost (atf3r@localhost) by mamba.cs.Virginia.EDU (8.7.5/8.7.3) with SMTP id XAA07679; Mon, 27 Apr 1998 23:32:56 -0400 (EDT) X-Authentication-Warning: mamba.cs.Virginia.EDU: atf3r owned process doing -bs Date: Mon, 27 Apr 1998 23:32:55 -0400 (EDT) From: "Adrian T. Filipi-Martin" Reply-To: Adrian Filipi-Martin To: "David E. Cross" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, David E. Cross wrote: > I was recenlty shown AIX's SIGDANGER (33). It is a signal that the kernel > issues to [some] running processes when it gets dangerously low on space, > by default SIGDANGER causes programs to die, freeing up memory, system > critical processes and server processes woulf be compiled to ignore > SIGDANGER. This seems like a very good idea, could it be done in FreeBSD? > I remember someone talking about changing the signal structs to be an > array of INTs, instead of just an int to accomidate more than 32 signals. > > Thoughts? I always thought SIGDANGER was considered the worst of all bad ideas. It greatly reduces determinism because when you over allocate memory and then discover that you are short on memory the process that is SIGDANGERED is randomly chosen randomly from the offending process group. It may not even be a process that improves the situation when dead. The best example of this was create 50 of the following processes: /* sleeper.c */ #include int main() { for(;;) sleep(30); return 0; } Then run the following: /* danger.c */ #include const int TwoGB = 2*1024*1024*1024; const int TwoMB = 2*1024*1024; int main() { char *p = (char *) malloc (TwoGB); for (i = 0; i < TwoGB; i += TwoMB) p[i] = 0; return 0; } When I ran this basic example on an AIX box years ago, a buch of the sleepers get killed before the danger process does. Why kill them? They have only minimal resources allocated. I believe it also breaks the POSIX definition of malloc(3), if I am not mistaken. Perhaps IBM had this ammended after introducing this misfeature. Caveat: I haven't messed with AIX boxes in a few years, so things may have improved, but I am naturally pessimistic when it comes to vendors fixing "great ideas". Adrian -- adrian@virginia.edu ---->>>>| If I were stranded on a desert island, and System Administrator --->>>| I could only have one OS for my computer, Neurosurgical Visualization Lab ->>| it would be FreeBSD. Think about it..... http://www.nvl.virginia.edu/ ->| http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message