Return to BSD News archive
Newsgroups: comp.unix.bsd 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!ix.netcom.com!netcom.com!bakul From: bakul@netcom.com (Bakul Shah) Subject: Re: Why select() returns ``exceptional'' for files? Message-ID: <bakulD33vxv.KIt@netcom.com> Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <3fois1$5d5@shore.shore.net> <bakulD2un2v.JDI@netcom.com> <3g15jb$rs2@nova.netapp.com> <bakulD2wLz4.5Gn@netcom.com> <3g65hg$2ns@nova.netapp.com> Date: Sat, 28 Jan 1995 08:08:19 GMT Lines: 60 guy@netapp.com (Guy Harris) writes: >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: Sigh.... In my earlier message I assumed that one would do the right thing (ie. extend NFS) and only that (ie. no polling solution). Hence systems running earlier versions won't get any new benefits. So in my earlier message I did mean what I said. Sorry if I was not clear and also because I later confused you by saying this: >>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. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I had rejected this in my earlier message (because polling does not scale too well). But later on I realized that this may be a useful thing for NFS 2 & 3 (*provided* that does not end up as an excuse to *not* fix NFS). You have to realize that (unlike, perhaps, for you) for me this is mostly an abstract but interesting problem and as I think more about it my understanding of the problem and solutions may change. Will change! >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. I don't know. Seems to me that if there was a protocol that did cache consistency, select-on-exceptional-condition-on-files (SOECOF) would be almost for free. Cache consistency is much more useful than SOECOF. Cache consistency would be a major quantum jump in functionality while SOECOF jumps up by one energy state but if it were implemented you can build some kind of semi cache consistency on top of that and then one would be stuck with having to support that. Bakul Shah <bakul@netcom.com>