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.