Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!basser.cs.su.oz.au!news.cs.su.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!Germany.EU.net!netmbx.de!zib-berlin.de!zrz.TU-Berlin.DE!cs.tu-berlin.de!klier
From: klier@cs.tu-berlin.de (Jan Klier)
Newsgroups: comp.os.386bsd.development
Subject: Re: Notes on the *new* FreeBSD V1.1 VM system
Date: 22 Feb 1994 15:20:18 GMT
Organization: Technical University of Berlin, Germany
Lines: 32
Message-ID: <2kd7ri$92t@news.cs.tu-berlin.de>
References: <BcxpGux.dysonj@delphi.com> <MYCROFT.94Feb20102534@duality.gnu.ai.mit.edu> <CLL9J6.FCF@endicor.com>
NNTP-Posting-Host: jet.cs.tu-berlin.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
tsarna@endicor.com (Ty Sarna) writes:
>IMHO, each of these behaviors is almost equally unpallatable. If I'm
>running an important process (say a long-running memory-hungry
>application such as ray-tracing, database server, or whatever), and the
>system decides to kill it arbitrarily, it might as well have paniced as
>far as I'm concerned. In either case, my processes get killed with no
>warning or chance to avoid it. AIX implemented the killing behavior,
>and there were so many complaints from customers (database servers
>getting killed and corrupting the database, etc) that I believe they
>finally changed it.
Only that under normal circumstances you cannot assume that you are the
only user on that machine. It might not make a difference for you, if the
machine panicked or if it kileed your process, but it might make a
difference for other users who share the machine with you.
Also, if the machine panicked, it must boot again. If it simply killed
a process you can instantly continue to work.
And the aspect about the error message is, that malloc is not the only
function that can cause a swapspace overflow. There are other situations
(e.g. growing stack due to a large number of recursive calls) where the
cause is not a function call which can return an error code, if this
happens.
jan
--
*********** Freedom is inversely proportional to security ******************
Jan Klier Berlin, Germany
e-mail: klier@cs.tu-berlin.de CIS: 100022,1700
jklier@ipk.fhg.de 100022.1700@compuserve.com