Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!rutgers!mcnc!rti!sheol!throopw From: throopw@sheol.UUCP (Wayne Throop) Newsgroups: comp.arch Subject: Re: Computer time measurements (Was Re: 64 bits for times....) Summary: I think fine time granularity *is* needed, but for other reasons Message-ID: <0878@sheol.UUCP> Date: 26 Aug 90 19:06:09 GMT References: Lines: 27 > From: meissner@osf.org (Michael Meissner) > But I already see the need for at least microsecond resolution in > filestamps. A second is fairly long these days with the faster > processors, and things like make are forced to use second > ganualarity. Well... I agree that computers can accomplish quite a lot in a second these days, and recording filesystem events at second granularity is getting about as useful as recording them with hour (or maybe even day) granularity. BUT... the fact that make uses the filesystem's timestamp as an up-to-date indicator is an abomination. It simply isn't a reasonable criteria. Consider the case of loading (or otherwise retrieving) a .h file from tape (or other backup, archive, or configuration management database). The archiver (or whatever) has every reasonable cause to preserve the date on that .h file, but if it does, make can become arbitrarily confused. Clearly, make should NOT depend on filesystem timestamps alone to store the state of a build. It badly needs a "lookaside database" of additional information. But then... that's an old pet peeve of mine... -- Wayne Throop !mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org