[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-arch
Subject: Re: Modifying file access time upon exec...
From: Max Okumoto <okumoto () ucsd ! edu>
Date: 2005-05-31 20:54:51
Message-ID: 429CCF1B.1060702 () ucsd ! edu
[Download RAW message or body]
Bruce Evans wrote:
[lots of stuff deleted]
>
> The 10-second granularity might be useful here. stat() on the other
> client would still need to sync with local caches/marks for update on
> other clients, but the other clients and the server can know that there
> is no need to sync if less than 10 seconds has elapsed since the
> last tick of the 1/10 Hz clock that gives the time to possibly update
> (this clock must be synchronized).
>
> This wouldn't work for mtimes. The granularity must be much less than
> 10 seconds for make(1) to work. I'm surprised it mostly works with a
> granularity of 1 second.
>
I can't confirm this yet, since I have not gotten to that part of
make. But from the docs, it looks like make(1) caches the stat()
info. Which might explain why it mostly works over NFS.
make docs in the usr.bin/make/PSD.doc/tutorial.ms Section 4.1
Something you should know about the way search paths are
implemented is that each directory is read, and its contents
cached, exactly once -- when it is first encountered -- so
any changes to the directories while PMake is running will
not be noted when searching for implicit sources, nor will
they be found when PMake attempts to discover when the file
was last modified, unless the file was created in the cur-
rent directory. While people have suggested that PMake
should read the directories each time, my experience sug-
gests that the caching seldom causes problems. In addition,
not caching the directories slows things down enormously
because of PMake's attempts to apply transformation rules
through non-existent files -- the number of extra file-sys-
tem searches is truly staggering, especially if many files
without suffixes are used and the null suffix isn't changed
from .out.
Max Okumoto
[stuff deleted]
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic