Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!ihnp4.ucsd.edu!sdd.hp.com!vixen.cso.uiuc.edu!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!pipex!uunet!Germany.EU.net!news From: bs@Germany.EU.net (Bernard Steiner) Newsgroups: comp.os.386bsd.development Subject: Re: Notes on the *new* FreeBSD V1.1 VM system Date: 25 Feb 1994 13:22:35 +0100 Organization: EUnet Deutschland GmbH, Dortmund, Germany Lines: 20 Distribution: world Message-ID: <2kkqib$h2h@Germany.EU.net> References: <BcxpGux.dysonj@delphi.com> <2ke3ss$l0d@u.cc.utah.edu> <Ja4p+zR.dysonj@delphi.com> <2kfcur$dd1@germany.eu.net> <2kgdcd$mls@usenet.pa.dec.com> NNTP-Posting-Host: qwerty.germany.eu.net In article <2kgdcd$mls@usenet.pa.dec.com>, paik@mlo.dec.com (Samuel S. Paik) writes: |> 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). Since you have no a-prioro knowledge of a processes behaviour wrt memory consumtion, the first two solutions are unviable. So we end up discussing the latter two, and (I think) we agree that the stick-head-in-the-mud behaviour is not a real solution. Since the killing solution may be regarded as very unfriendly, I was merely suggesting a possible (?) way to allow well-behaved processes to tell the system how much a user would frown upon the system killing that particular process. Bernard