From owner-freebsd-current Wed Jan 20 16:25:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA08793 for freebsd-current-outgoing; Wed, 20 Jan 1999 16:25:17 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mail.kersur.net (mail.kersur.net [199.79.199.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08768 for ; Wed, 20 Jan 1999 16:25:06 -0800 (PST) (envelope-from dswartz@druber.com) Received: from manticore (manticore.druber.com [207.180.95.108]) by mail.kersur.net (8.9.1/8.9.1) with SMTP id TAA05726; Wed, 20 Jan 1999 19:26:30 -0500 (EST) Message-Id: <3.0.5.32.19990120192420.0097b5f0@mail.kersur.net> X-Sender: druber@mail.kersur.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 20 Jan 1999 19:24:20 -0500 To: Mike Smith From: Dan Swartzendruber Subject: Re: Truth to M_WAITOK? Cc: Bruce Evans , green@unixhelp.org, mike@smith.net.au, current@FreeBSD.ORG In-Reply-To: <199901202346.PAA04181@dingo.cdrom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 03:46 PM 1/20/99 -0800, Mike Smith wrote: >> >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. > >Bear with the ignorance a moment; how is a full map any different to no >more kmem space? > >In the "out of kmem" case, we call VM_WAIT and retry. Why not do this >in the kmem_map full case as well? I've stayed out of this until now, but here's my 2 cents. I never understood why so much Unix code can't be bothered to check error codes. If the semantics for a procedure are to return NULL if it can't get the buffer without waiting, fine. I don't understand why that implies that specifying that you are willing to wait means the routine can never fail. If it is true that an allocation routine will never normally fail when WAITOK is specified, that still doesn't mean that some implementation or other couldn't return NULL on some kind of pathological error. Maybe not in this subsystem, but I don't like the precedent that is set. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message