Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 May 2002 13:04:00 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Bosko Milekic <bmilekic@unixdaemons.com>
Cc:        Peter Wemm <peter@wemm.org>, Richard Wenninger <richard@richardw.net>, current@FreeBSD.ORG
Subject:   Re: UMA lock
Message-ID:  <3CF53430.49B6F618@mindspring.com>
References:  <20020529061540.88CD6380A@overcee.wemm.org> <3CF475E3.8925781A@mindspring.com> <20020529091152.B61073@unixdaemons.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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*.


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

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?3CF53430.49B6F618>