Date: Wed, 20 Jan 1999 15:46:39 -0800 From: Mike Smith <mike@smith.net.au> To: Bruce Evans <bde@zeta.org.au> Cc: green@unixhelp.org, mike@smith.net.au, current@FreeBSD.ORG Subject: Re: Truth to M_WAITOK? Message-ID: <199901202346.PAA04181@dingo.cdrom.com> In-Reply-To: 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
> >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? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199901202346.PAA04181>