Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!caen!math.ohio-state.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: <bakulD2un2v.JDI@netcom.com> Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <3fois1$5d5@shore.shore.net> <3fpssn$2gk@nova.netapp.com> <bakulD2ss6p.7M4@netcom.com> <3fuupi$ji8@nova.netapp.com> Date: Mon, 23 Jan 1995 08:18:31 GMT Lines: 58 guy@netapp.com (Guy Harris) writes: >Bakul Shah <bakul@netcom.com> wrote: >>- Checking mail -- such notification is likely to be cheaper >> than the current polling method. >Cheaper, probably, although I don't know how *much* cheaper it'd be, as >I don't know how expensive the current polling method is with various >mailbox-watchers. It sure would've helped back when netcom had a 30,000+ files in its /var/spool/mail directory! Also, notification is more likely to scale better than polling (not always but for cases such as mail). >Perhaps you should have stated that as > It would not be all that painful to implement in a distributed > file system for which you control the protocol. No, control is not the issue; it is a given that NFS or any other such protocol would need to be changed in some way. What I was getting at was that the ``intellectual'' pain of implementation would not be all that bad. > 1) add on another service-on-the-side like the lock manager At least the lock manager would've been available on all platforms if the lock protocol was fully and openly specified and adhered to. If you made the protocol public and stuck to it, other implementations would crop up. > 2) do it by having the client poll the server to see if the > file's mod time or inode-change time has changed (as is > already done by NFS clients that cache data locally, to see > whether the cache needs to be invalidated - remember, most if > not all UNIX NFS clients cache data locally, even if they > just cache it in memory, not on disk). 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. Something as basic as change notification belongs in the FS protocol. Change notification can also be used to invalidate NFS client cahce data. [If a file is not _likely_ to change very often, it is less expensive in network traffic to register for change notification] >>There should be different exception conditions on attribute >>change vs. content change. >How would you make them different, given that "select()" only has >"exception conditions", not different kinds of exception conditions? You are right. I wasn't thinking too clearly :-) Bakul Shah <bakul@netcom.com>