From owner-freebsd-net Tue Aug 25 14:24:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08666 for freebsd-net-outgoing; Tue, 25 Aug 1998 14:24:16 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA08490; Tue, 25 Aug 1998 14:24:01 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id RAA03172; Tue, 25 Aug 1998 17:22:59 -0400 (EDT) (envelope-from wollman) Date: Tue, 25 Aug 1998 17:22:59 -0400 (EDT) From: Garrett Wollman Message-Id: <199808252122.RAA03172@khavrinen.lcs.mit.edu> To: Stefan Bethke Cc: freebsd-current@FreeBSD.ORG, net@FreeBSD.ORG Reply-To: net@FreeBSD.ORG Subject: Semantics of MGET(m, M_WAIT, *)? [was: Huge Bug not fixed?] In-Reply-To: References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Please watch followups!] < said: > What are the expected semantics of MGET(m, M_WAIT, *)? I would suggest > that by specifing M_WAIT, the caller wants to sleep until a mbuf becomes > available, as it is already the case if the vm map must be extended. It should sleep, but actually doing so while avoiding deadlocks is problematic. Since the mbuf allocator as currently formulated is going away, callers to mget should expect that the allocation might fail, but that M_WAIT makes it ``try harder'' as it were. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message