From owner-freebsd-current Wed May 29 4:43: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id DC1B137B41E for ; Wed, 29 May 2002 04:42:34 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA20658; Wed, 29 May 2002 21:36:33 +1000 Date: Wed, 29 May 2002 21:39:54 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Peter Wemm Cc: Terry Lambert , Richard Wenninger , Subject: Re: UMA lock In-Reply-To: <20020529072020.89F16380A@overcee.wemm.org> Message-ID: <20020529212412.U24797-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 29 May 2002, Peter Wemm wrote: > M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means > "you must not tsleep!". M_WAITOK conversely means that tsleep should be > called as needed. Things like malloc still can return NULL even with M_WAITOK > for non-recoverable scenarios. malloc() itself can't do this, unless malloc(M_WAITOK) has been broken. Thousands of callers depend on malloc(M_WAITOK) not returning NULL, and malloc.9 still documents this behaviour. You may be thinking of mbuf allocation. It is confusingly different, starting with the no-wait flag being spelled differently (M_NOWAIT). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message