From owner-freebsd-hackers Mon Apr 27 22:25:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA18355 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 22:25:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA18270 for ; Mon, 27 Apr 1998 22:24:52 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id WAA07368; Mon, 27 Apr 1998 22:24:41 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Adrian Filipi-Martin cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-reply-to: Your message of "Mon, 27 Apr 1998 23:32:55 EDT." Date: Mon, 27 Apr 1998 22:24:41 -0700 Message-ID: <7364.893741081@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. Argh.. You and everyone else arguing from this angle are all seriously missing the point here! A process can already be randomly selected for KAL-007 treatment due to resource limitations under the current scheme and it's something which has been true for literally years now - see some of Terry's old rants on the evils of memory over-commit if you want to revisit that old dead-horse topic and find out why things are the way they are today. All the SIGDANGER (Will Robinson) signal is meant to do is give a process a little _warning_ before it's chosen as the designated sacrifice for the evening and terminated in an untimely fashion. I don't think the question here is "is this a good idea" - it's a perfectly reasonable idea and one which has been proposed before. The question here is really "what are the proposed semantics of this mechanism?", e.g. how long do you wait from the time you SIGDANGER the process and actually shoot it down, and what happens if you're also critically short of resources and don't have much time to wait? Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message