Date: Thu, 20 Aug 1998 14:40:37 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: ac199@hwcn.org, Mike Smith <mike@smith.net.au> Cc: ac199@hwcn.org, joelh@gnu.org, hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <v04011707b202199e7df5@[128.113.24.147]> In-Reply-To: <Pine.BSF.3.96.980820014520.392H-100000@localhost> References: <199808192213.WAA00579@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 1:47 AM -0400 8/20/98, Tim Vanderhoek wrote:
>On Wed, 19 Aug 1998, Mike Smith wrote:
>
>> > by at least one unit (255ths, 1024ths, whatever), and then only
>> > resort to using duplicate times when it is forced to by benchmark
>> > programs that touch 1024 files per second just for kicks?
>>
>> It could simply be defeated by finding another pathalogical example.
>> Higher time resolution is the only way to fix it correctly.
>
> Sufficiently pathalogical examples defeat static resolutions (ie.
> any resolution that doesn't become finer as necessary).
First, let me reiterate that I do believe it would be good to
have resolution better than 1 second...
Having said that though, pathological situations make this pretty
much impossible to resolve, even if you have infinite precision
of when every file was last changed. Consider:
cc is compiling something.c, and reads in important.h
while cc is still compiling, some other process (maybe
running on a second CPU) modifies important.h
cc finishes, and writes out something.o
result: That something.o was *effectively* compiled with
the old important.h, even though the timestamps
of the two files would imply that something.o is
more recent than the new version of important.h
So, even infinite resolution won't really solve all the
pathological cases. Completely solving them would get
rather tricky, and probably involves changes to the 'make'
command.
Still, I do think I'd like to see something more than per-second
resolution for lastdatachange times on files...
---
Garance Alistair Drosehn = gad@eclipse.its.rpi.edu
Senior Systems Programmer or drosih@rpi.edu
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04011707b202199e7df5>