Date: Fri, 26 Oct 2001 14:57:42 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: tlambert2@mindspring.com, Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <p0510101db7ff501c2b27@[128.113.24.47]> In-Reply-To: <3BD993A6.E6B12512@mindspring.com> References: <2912.1004113233@critter.freebsd.dk> <3BD993A6.E6B12512@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0510101db7ff501c2b27>