Re: [PATCH 3/3] Avoid doing extra 'lstat()'s for d_type if we have an up-to-date cache entry

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, 9 Jul 2009, Junio C Hamano wrote:
> 
> Would dir/a be marked as uptodate in the index, if somebody preloads the
> index, after the above sequence?  I hope not.

Index preloading does not care about directories. It does the standard

	if (ie_match_stat(index, ce, &st, CE_MATCH_RACY_IS_DIRTY))
		continue;

and since it's all threaded (and the whole _point_ is that it's threaded), 
it can't do anything fancier. Our lstat cache is _not_ thread-safe.

But preloading isn't even the only thing to do that. All the merge logics 
also just do "ie_match_stat()", as does git checkout, although maybe the 
directory gets validated separately for those cases before recursion.

Looking at "ce_mark_uptodate()", I think diff-lib.c is the only one that 
actually does that whole "has_symlink_leading_path()" thing (in 
"check_removed()").

I guess we could make out lstat cache thread-safe, and have the callers 
pass in a per-thread "struct cache_def *". That would work well enough for 
preloading (and everybody else could just use some random static one and 
pass that in).

Added Kjetil to cc.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]