Date: Wed, 29 May 2002 16:22:14 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Peter Wemm <peter@wemm.org>, Richard Wenninger <richard@richardw.net>, current@FreeBSD.ORG Subject: Re: UMA lock Message-ID: <20020529162214.A62435@unixdaemons.com> In-Reply-To: <3CF53430.49B6F618@mindspring.com>; from tlambert2@mindspring.com on Wed, May 29, 2002 at 01:04:00PM -0700 References: <20020529061540.88CD6380A@overcee.wemm.org> <3CF475E3.8925781A@mindspring.com> <20020529091152.B61073@unixdaemons.com> <3CF53430.49B6F618@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 29, 2002 at 01:04:00PM -0700, Terry Lambert wrote: > Bosko Milekic wrote: > > On Tue, May 28, 2002 at 11:32:03PM -0700, Terry Lambert wrote: > > > Can we get rid of the NULL tests we had to put in when M_WAIT > > > turned into M_WAITOK? > > > > No. What you see as a bad thing others (including me) see as a good > > thing. I _want_ to be able to say: "okay, try sleeping; but I realize > > that sleeping for longer than some reasonable time if I'm not getting > > anything to begin with will probably not get me anything at any point > > so tell me the allocation really failed and give me the opportunity to > > clean up before *I* decide what I want to do." > > Up the operating system's wazoo! > > *We* are the programmers. > > *We* know better than *it* whether it's OK to sleep indefinitely > or not. > > If *we* want the allocation to fail after *some reasonable time*, > then *we will damn well set a timer to "some reasonable time"* to > indicate that fact to the OS. > > If *we* do *not* damn well set a timer, then *we* damn well do not > want it to fail, *we* want it to hang either *until it succeeds* or > *until hell freezes over* or *until we manually enter the kernel > debugger to find out why it is hanging*. Then *you* can set *your* timer to hang to infinity. *I* have provided *the* ability to do *that*: tesla# sysctl -A | grep mbuf_wait kern.ipc.mbuf_wait: 32 tesla# sysctl -w kern.ipc.mbuf_wait=0 (Now the mbuf code will behave in such a way that it will hang forever if you call with M_TRYWAIT and cannot allocate anything). However, *I* want to be able to do otherwise, because *I* don't agree with *you*. So *I* will leave my timer to whatever the hell I please and *I* will require callers to check for NULL in all cases, and handle the failure appropriately, because that's what good systems do. If for my particular chunk of code or subsystem, "properly" means "call panic()," then so be it. But if for my particular subsystem it happens to be *SOMETHING OTHER THAN CALLING panic()*, I want to be able to catch that failure and handle it after the wait has timed out. If there is code that still uses M_TRYWAIT with the mbuf allocator and does not check for NULL (I believe there is still some of this), well, then, it will simply page fault immediately after it tries dereferencing the NULL pointer and I'll figure it right out. > All these people are bitching about kludging around something by > changing M_WAITOK to M_NOWAIT. > > The kludge is *already there* in M_WAITOK, whether you want it > or not. > > So bitching about this kluge is meaningless: changing it back to > M_WAITOK won't make the little F'er go away, it will just *hide* > the kludge from people to lazy to read the code all the way down, > and know *why* they have to check for a NULL return from a call > that's *supposed to wait* until it's return will *not* be NULL. > > -- Terry > -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org 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?20020529162214.A62435>