From owner-freebsd-current  Mon Jan 18 13:41:32 1999
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA16198
          for freebsd-current-outgoing; Mon, 18 Jan 1999 13:41:32 -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 NAA16193
          for <current@FreeBSD.ORG>; Mon, 18 Jan 1999 13:41:29 -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 IAA14501;
	Tue, 19 Jan 1999 08:41:21 +1100
Date: Tue, 19 Jan 1999 08:41:21 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199901182141.IAA14501@godzilla.zeta.org.au>
To: current@FreeBSD.ORG, julian@whistle.com
Subject: Re: kernel malloc and M_CANWAIT
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>There was some talk about the fact that malloc(..M_CANWAIT)
>can now return with a failure.

You mean M_WAITOK.

>Is that true?

Of course not.  It is fundamental that malloc(..., M_WAITOK) either
succeeds or panics.  Most callers depend on this and don't check for
success.  The others are bogus.

You may be thinking of the documented but unimplemented new flag
M_ASLEEP.  It's hard to see what this does (since it is
unimplemented), but the docs say to only use it with M_NOWAIT.

Bruce

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