From owner-freebsd-arch Fri Oct 26 11:57:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 5042E37B407 for ; Fri, 26 Oct 2001 11:57:48 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9QIvjJ64914; Fri, 26 Oct 2001 14:57:45 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3BD993A6.E6B12512@mindspring.com> References: <2912.1004113233@critter.freebsd.dk> <3BD993A6.E6B12512@mindspring.com> Date: Fri, 26 Oct 2001 14:57:42 -0400 To: tlambert2@mindspring.com, Poul-Henning Kamp From: Garance A Drosihn Subject: Re: 64 bit times revisited.. Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Also: no one has ever justified this for anything other >than "make", which looks only at mtime, so having such >high resolution for atime and ctime is really not necessary, >unless it can be justified. >The "mtime" argument is really only valid in the case that >you rerun a build in a subsecond time with generated source >code, such that the generate code ends up with the same >mtime timestamp as the previously generated object code. I >fully admit that subsecond resolution on mtime is necessary >to avoid stale files in the case that you can regenerate >them with different contents in under a second since the >previous build. As an aside, let me make an observation about 'make'. It is just an observation about 'make' and timestamps though. I do completely support the idea of having higher-resolution timestamps for many purposes, including 'mtime'. However, when the specific example of 'make' comes up, I think people are naive to think that even infinite-resolution timestamps will fully address the issue of make. When 'make' is processing it: a) checks timestamps of source files vs target b) noticed target is out-of-date. c) executes commands to create the new target d) at the end of all those commands, a new timestamp is set on the target file. Step c can be many commands, and can easily require millions or billions of instructions. It can not be done in zero time. If any *other* process changes any of the source files at the same time that 'make' is doing steps b&c, then the target should be remade, but the timestamp set in step d will be "after" the change made to the source file. So, we should have higher-resolution timestamps, but they will not really solve all the problems of 'make'... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message