From owner-freebsd-hackers Thu Aug 20 12:14:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03707 for freebsd-hackers-outgoing; Thu, 20 Aug 1998 12:14:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03700 for ; Thu, 20 Aug 1998 12:14:22 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.147] (lucky.dynamic.rpi.edu [128.113.24.147]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id OAA57412; Thu, 20 Aug 1998 14:36:49 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: References: <199808192213.WAA00579@dingo.cdrom.com> Date: Thu, 20 Aug 1998 14:40:37 -0400 To: ac199@hwcn.org, Mike Smith From: Garance A Drosihn Subject: Re: proposal to not change time_t Cc: ac199@hwcn.org, joelh@gnu.org, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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