From: Michael Haggerty <mhagger@alum.mit.edu>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Johan Herland <johan@herland.net>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 2/4] add a stat_validity struct
Date: Mon, 13 May 2013 04:29:34 +0200 [thread overview]
Message-ID: <5190500E.8060907@alum.mit.edu> (raw)
In-Reply-To: <20130507023942.GB22940@sigill.intra.peff.net>
On 05/07/2013 04:39 AM, Jeff King wrote:
> It can sometimes be useful to know whether a path in the
> filesystem has been updated without going to the work of
> opening and re-reading its content. We trust the stat()
> information on disk already to handle index updates, and we
> can use the same trick here.
>
> This patch introduces a "stat_validity" struct which
> encapsulates the concept of checking the stat-freshness of a
> file. It is implemented on top of "struct cache_entry" to
> reuse the logic about which stat entries to trust for a
> particular platform, but hides the complexity behind two
> simple functions: check and update.
Given that "struct cache_entry" holds a lot of information that is
irrelevant to stat-freshness and that ce_match_stat_basic() has a lot of
logic that is geared towards cache_entries, it seems like there should
be some kind of "struct stat_data" that holds the portion of the stat
information that we use for checking whether a file might have been
changed between two accesses. cache_entry would contain a stat_data as
a member, and the functionality for checking that part of a cache_entry
validity would be moved to a separate function.
Then your "struct validity_info" could hold a pointer to a stat_data
rather than to a cache_entry, and it wouldn't have to contain the
unrelated cache_entry stuff.
I'll send patches shortly to show what I mean.
Michael
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This one is prep for the next patch. I'm not super-happy with the way it
> builds around cache_entry, just because cache entries may end up
> following different rules in the long run. But I at least tried to
> encapsulate the grossness, so if it turns out to be a problem, we can
> factor out the relevant bits from ce_match_stat_basic into a shared
> function.
>
> cache.h | 27 +++++++++++++++++++++++++++
> read-cache.c | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 58 insertions(+)
>
> diff --git a/cache.h b/cache.h
> index 94ca1ac..adf2874 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1326,4 +1326,31 @@ int sane_execvp(const char *file, char *const argv[]);
>
> int sane_execvp(const char *file, char *const argv[]);
>
> +/*
> + * A struct to encapsulate the concept of whether a file has changed
> + * since we last checked it. This is a simplified version of the up-to-date
> + * checks we use for the index. The implementation is built on an index entry,
> + * but we shield the callers from that ugliness with our struct.
> + */
> +struct stat_validity {
> + struct cache_entry *ce;
> +};
> +
> +void stat_validity_clear(struct stat_validity *sv);
> +
> +/*
> + * Returns 1 if the path matches the saved stat_validity, 0 otherwise.
> + * A missing or inaccessible file is considered a match if the struct was just
> + * initialized, or if the previous update found an inaccessible file.
> + */
> +int stat_validity_check(struct stat_validity *sv, const char *path);
> +
> +/*
> + * Update the stat_validity from a file opened at descriptor fd (if the file
> + * is missing or inaccessible, the validity will reflect that, and future
> + * calls to stat_validity_check will match only if it continues to be
> + * inaccessible).
> + */
> +void stat_validity_update(struct stat_validity *sv, int fd);
> +
> #endif /* CACHE_H */
> diff --git a/read-cache.c b/read-cache.c
> index 04ed561..a0bd06c 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1933,3 +1933,34 @@ void *read_blob_data_from_index(struct index_state *istate, const char *path, un
> *size = sz;
> return data;
> }
> +
> +void stat_validity_clear(struct stat_validity *sv)
> +{
> + free(sv->ce);
> + sv->ce = NULL;
> +}
> +
> +int stat_validity_check(struct stat_validity *sv, const char *path)
> +{
> + struct stat st;
> +
> + if (stat(path, &st) < 0)
> + return sv->ce == NULL;
> + if (!sv->ce)
> + return 0;
> + return !ce_match_stat_basic(sv->ce, &st);
> +}
> +
> +void stat_validity_update(struct stat_validity *sv, int fd)
> +{
> + struct stat st;
> +
> + if (fstat(fd, &st) < 0)
> + stat_validity_clear(sv);
> + else {
> + if (!sv->ce)
> + sv->ce = xcalloc(1, cache_entry_size(0));
> + fill_stat_cache_info(sv->ce, &st);
> + sv->ce->ce_mode = create_ce_mode(st.st_mode);
> + }
> +}
>
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2013-05-13 2:29 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-03 8:38 another packed-refs race Jeff King
2013-05-03 9:26 ` Johan Herland
2013-05-03 17:28 ` Jeff King
2013-05-03 18:26 ` Jeff King
2013-05-03 21:02 ` Johan Herland
2013-05-06 12:12 ` Michael Haggerty
2013-05-06 18:44 ` Jeff King
2013-05-03 21:21 ` Jeff King
2013-05-06 12:03 ` Michael Haggerty
2013-05-06 18:41 ` Jeff King
2013-05-06 22:18 ` Jeff King
2013-05-07 4:32 ` Michael Haggerty
2013-05-07 4:44 ` Jeff King
2013-05-07 8:03 ` Michael Haggerty
2013-05-07 2:36 ` [PATCH 0/4] fix packed-refs races Jeff King
2013-05-07 2:38 ` [PATCH 1/4] resolve_ref: close race condition for packed refs Jeff King
2013-05-12 22:56 ` Michael Haggerty
2013-05-16 3:47 ` Jeff King
2013-05-16 5:50 ` Michael Haggerty
2013-05-12 23:26 ` Michael Haggerty
2013-06-11 14:26 ` [PATCH 0/4] Fix a race condition when reading loose refs Michael Haggerty
2013-06-11 14:26 ` [PATCH 1/4] resolve_ref_unsafe(): extract function handle_missing_loose_ref() Michael Haggerty
2013-06-11 14:26 ` [PATCH 2/4] resolve_ref_unsafe(): handle the case of an SHA-1 within loop Michael Haggerty
2013-06-11 14:26 ` [PATCH 3/4] resolve_ref_unsafe(): nest reference-reading code in an infinite loop Michael Haggerty
2013-06-11 14:26 ` [PATCH 4/4] resolve_ref_unsafe(): close race condition reading loose refs Michael Haggerty
2013-06-12 8:04 ` Jeff King
2013-06-13 8:22 ` Thomas Rast
2013-06-14 7:17 ` Michael Haggerty
2013-06-11 20:57 ` [PATCH 0/4] Fix a race condition when " Junio C Hamano
2013-05-07 2:39 ` [PATCH 2/4] add a stat_validity struct Jeff King
2013-05-13 2:29 ` Michael Haggerty [this message]
2013-05-13 3:00 ` [RFC 0/2] Separate stat_data from cache_entry Michael Haggerty
2013-05-13 3:00 ` [RFC 1/2] Extract a struct " Michael Haggerty
2013-05-13 3:00 ` [RFC 2/2] add a stat_validity struct Michael Haggerty
2013-05-13 5:10 ` [RFC 0/2] Separate stat_data from cache_entry Junio C Hamano
2013-05-16 3:51 ` [PATCH 2/4] add a stat_validity struct Jeff King
2013-05-07 2:43 ` [PATCH 3/4] get_packed_refs: reload packed-refs file when it changes Jeff King
2013-05-07 2:54 ` [PATCH 0/2] peel_ref cleanups changes Jeff King
2013-05-07 2:56 ` [PATCH 1/2] peel_ref: rename "sha1" argument to "peeled" Jeff King
2013-05-07 3:06 ` [PATCH 2/2] peel_ref: refactor for safety with simultaneous update Jeff King
2013-05-09 19:18 ` [PATCH 3/4] get_packed_refs: reload packed-refs file when it changes Eric Sunshine
2013-05-13 2:43 ` Michael Haggerty
2013-05-07 2:51 ` [PATCH 4/4] for_each_ref: load all loose refs before packed refs Jeff King
2013-05-07 6:40 ` [PATCH 0/4] fix packed-refs races Junio C Hamano
2013-05-07 14:19 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5190500E.8060907@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johan@herland.net \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.