This is the mail archive of the
cygwin@sources.redhat.com
mailing list for the Cygwin project.
Re: Optimizing away "ReadFile" calls when Make calls stat()
At 02:17 PM 2/13/2001, jik-cygwin@curl.com wrote:
> > Date: Tue, 13 Feb 2001 14:08:58 -0500
> > From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
> >
> > >1) The cache would have to be automatically invalidated whenever the
> > > file is changed, and you'd thus need to check if a file has changed
> > > before using the cache, and those checks would themselves take
> > > time.
> >
> > I'd submit that while this may be true in general, it shouldn't be in the
> > case of symbolic links and executables. These attributes don't really change
> > or, if they do, they change in a very defined way which should make it
> > possible to track.
>
>Yikes, I don't agree with that at all.
>
>Non-deterministic behavior is *much* worse than slow behavior. It
>would be *impossible* for Cygwin to track every single change to
>symbolic links and/or executable files, since people can modify such
>files without going through Cygwin at all (e.g., modifying them
>directly with a Windows app, or modifying such a file on a SAMBA mount
>through Linux).
>
>Since it's impossible for Cygwin to know when such files are changed
>out from under it, it *must* check them, or at least check if they
>have been changed, each time they are accessed.
Again, in general, I agree with you. Still, it depends on what attributes
are being cached. If we limit ourselves to checking for executables and
symbolic links, I don't see a major problem. The only thing that this won't
catch is places which someone changes their executable file to a
non-executable or vice versa (same for symbolic link files). Assuming the
cache ages relatively quickly, this shouldn't be an issue. Your point is
taken however.
Larry Hall lhall@rfk.com
RFK Partners, Inc. http://www.rfk.com
118 Washington Street (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple