Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.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!gatech!swrinde!sgiblab!gatekeeper.us.oracle.com!decwrl!pa.dec.com!paik
From: paik@mlo.dec.com (Samuel S. Paik)
Newsgroups: comp.os.386bsd.development
Subject: Re: Notes on the *new* FreeBSD V1.1 VM system
Date: 23 Feb 1994 20:13:01 GMT
Organization: Digital Equipment Corporation, 3D Device Support
Lines: 22
Message-ID: <2kgdcd$mls@usenet.pa.dec.com>
References: <BcxpGux.dysonj@delphi.com> <2ke3ss$l0d@u.cc.utah.edu> <Ja4p+zR.dysonj@delphi.com> <2kfcur$dd1@germany.eu.net>
NNTP-Posting-Host: ddxrsj.mlo.dec.com
In article <2kfcur$dd1@germany.eu.net>,
Bernard Steiner <bs@Germany.EU.net> wrote:
>How about (just a thought, so don't punch my nose if it doesn't work) adding
>some sort of system call that enables processes to tell the kernel "please
>don't kill me unless you are about to crash anyway" with maybe something like
>a priority so that pretty useless things like xfaces, xclock, etc get killed
>first.
This is worse than "Worse is Better".
Please go read the deadlock literature. There are basically four "solution
strategies" to deadlock: prevention by allowing resources to be allocated
only in certain patterns; avoidance by refusing to allocate resources when
you may end up with a deadlock; detection when it occurs and killing to
break the deadlock; and stick head in the mud (unix).
--
Samuel Paik / Digital Equipment Corporation / 3D Device Support
paik@mlo.dec.com / 508-493-4048 / I speak only for myself
"One of these days I'm going to say the wrong thing to the wrong mage and
I'll be spending the rest of my days searching for Mrs. Right Toad."
-- Elf Sternberg