From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 26 Jan 2015 20:22:12 -0800 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3ba11194-ead9-11e9-9d60-3106f5b1d025 > many of resource exhaustion come from careless programming. > I would like such processes to be killed immediately. > throwing up to broken state might be better. at the danger of repeating myself, the linux oom killer fills a similar role. its job is to try to identify the process that caused the box to run out of memory and kill it. it's a dasterdly beast that's wrong alot. this isn't because it isn't thoughtfully and well built, it's because the "right" program to kill is not expressed by the system. the oom killer has to guess. i think it will go the same way with fork protection. how do you tell which program is at fault? how do you tell a program forking at high frequency, with short lived children from a fork bomb? (such as a busy web server.) > I prefer an option to plan9.ini that enable resrcwait(), because the call breaks > traditional programming style and probably we need more time to have > right solution. i'm not sure i understand what you mean by "traditional programming style" here as plan 9 exists in part to break unix rules. - erik