*BSD News Article 41569


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!swrinde!emory!nntp.msstate.edu!olivea!nntp-sc.barrnet.net!netapp.com!netapp.com!not-for-mail
From: guy@netapp.com (Guy Harris)
Newsgroups: comp.unix.bsd
Subject: Re: Why select() returns ``exceptional'' for files?
Date: 25 Jan 1995 10:33:20 -0800
Organization: Network Appliance Corporation
Lines: 45
Message-ID: <3g65hg$2ns@nova.netapp.com>
References: <3fois1$5d5@shore.shore.net> <bakulD2un2v.JDI@netcom.com> <3g15jb$rs2@nova.netapp.com> <bakulD2wLz4.5Gn@netcom.com>
NNTP-Posting-Host: 192.9.200.13

Bakul Shah <bakul@netcom.com> wrote:
>guy@netapp.com (Guy Harris) writes:
>
>>Bakul Shah <bakul@netcom.com> wrote:
>>>Polling would not scale too well.  The `right' thing to do (IMHO
>>>and ideally speaking) is to extend NFS.  On systems running
>>>earlier versions one would not get the new benefits but so what.
>
>>Which benefits?
>
>>If you mean the benefits of being able to run applications using selects
>>on exceptional conditions on files to block until the file changes, I
>
>Yes, these benefits.

No, that's *NOT* what you meant, given that you later said:

>I can sort of see a way to do
>this with a wart-on-the-side protocol that'd work with NFS2/3 and
>that does not use polling (if block-until-change is implemented
>on both client and server) and with polling if exception on
			    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>change is not implemented on the server side.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

...which means that, on clients that don't implement the change, or
clients mounting stuff from servers that don't implement the change, you
*STILL* get to run applications that use selects on exceptional
conditions on files to block until the file changes, you just require
the client to poll the server (which is what you get now with something
that periodically "stat"s or "fstat"s the file).

I.e., by "the new benefits", you definitely were *not* referring to the
benefits of select-on-exceptional-condition, period, you were referring
to the benefits of an *NFS implementation* of
select-on-exceptional-condition that doesn't require the client to poll
the server.

That way, the issue of select-on-exceptional-condition on files, and of
changes to the NFS protocol to do stronger cache consistency (which is
what eliminating polling for this case really implies, as far as I can
tell), are decoupled - which, as far as I'm concerned, is as it should
be, as there's no reason to deny people any benefits that might accrue
from select-on-exceptional-condition on files merely because we don't
have strong(er) cache consistency for NFS.