Date: Wed, 20 Jan 1999 19:24:20 -0500 From: Dan Swartzendruber <dswartz@druber.com> To: Mike Smith <mike@smith.net.au> Cc: Bruce Evans <bde@zeta.org.au>, green@unixhelp.org, mike@smith.net.au, current@FreeBSD.ORG Subject: Re: Truth to M_WAITOK? Message-ID: <3.0.5.32.19990120192420.0097b5f0@mail.kersur.net> In-Reply-To: <199901202346.PAA04181@dingo.cdrom.com> References: <Your message of "Thu, 21 Jan 1999 10:46:57 %2B1100." <199901202346.KAA13074@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.5.32.19990120192420.0097b5f0>