From owner-freebsd-current  Wed Jan 20 15:47:16 1999
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id PAA04367
          for freebsd-current-outgoing; Wed, 20 Jan 1999 15:47:16 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA04362
          for <current@FreeBSD.ORG>; Wed, 20 Jan 1999 15:47:13 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id KAA13074;
	Thu, 21 Jan 1999 10:46:57 +1100
Date: Thu, 21 Jan 1999 10:46:57 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199901202346.KAA13074@godzilla.zeta.org.au>
To: green@unixhelp.org, mike@smith.net.au
Subject: Re: Truth to M_WAITOK?
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>It looks like M_WAITOK will either return non-NULL or panic; it 
>shouldn't be capable of returning NULL.  Ideally, it shouldn't panic 
>either (why is it only that M_WAITOK can panic, and M_NOWAIT can't?).

Because failures for M_NOWAIT are normal (all pages may be in use,
and the caller is not prepared for pages top be freed by swapping).
Therefore, callers that set M_NOWAIT must be prepared for failure.  OTOH,
failures for M_WAITOK are abnormal, and at least for map == kmem_map (as
it is for calls to kmem_malloc() from malloc()), the correct handling
for failure is to panic since a full map is unlikely to become unfull
and neither the caller or kmem_malloc() can know what to do to unfill it.

Bruce

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