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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to