From owner-freebsd-hackers  Wed Jul 14 16:16:48 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP id 97C8E14DE5
	for <freebsd-hackers@FreeBSD.ORG>; Wed, 14 Jul 1999 16:16:42 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA97134;
	Wed, 14 Jul 1999 16:16:20 -0700 (PDT)
	(envelope-from dillon)
Date: Wed, 14 Jul 1999 16:16:20 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199907142316.QAA97134@apollo.backplane.com>
To: Nate Williams <nate@mt.sri.com>
Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org
Subject: Re: Replacement for grep(1) (part 2)
References: <199907132110.OAA23817@lestat.nas.nasa.gov>
	<199907132114.OAA80781@apollo.backplane.com>
	<877lo4z0pe.fsf@redmail.redback.com>
	<199907132212.PAA81234@apollo.backplane.com>
	<871zecyx0k.fsf@redmail.redback.com>
	<199907142234.QAA29442@mt.sri.com>
	<199907142245.PAA96901@apollo.backplane.com>
	<199907142249.QAA29554@mt.sri.com>
	<199907142302.QAA97044@apollo.backplane.com> <199907142309.RAA29776@mt.sri.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:
:Returning NULL isn't an error, it's an indication that there is no more
:memory.  Don't think if it as an error, think of it as a hint. 

    It's only a hint if it is returned due to the process resource limit
    being hit.  If it is returned due to the system running out of swap,
    it would be an error.

    Look at it this way:  Processes run in their own VM address space and
    should theoretically be unaffected by other processes.  If your resource
    limits allow a process, say, 32MB of ram, the process should be confident
    in its ability to utilize that much if it needs to without running out of
    memory.  This is what FreeBSD and most UNIX's give to processes.

    But if you change the rules so that process A can run the system out of
    swap (or, in the case of a non-overcommit model, out of reservable
    space), then process B can get allocation errors without even coming close
    to their allocation limit.

    This creates a dependancy between two completely independant processes
    possibly owned two totally unrelated users.  This is not acceptable,
    and is precisely why this sort of behavior does not occur.

							-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message