1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-05-03 22:28:09 +02:00
git/replace-object.h

64 lines
2.1 KiB
C
Raw Permalink Normal View History

#ifndef REPLACE_OBJECT_H
#define REPLACE_OBJECT_H
#include "oidmap.h"
#include "repository.h"
#include "object-store-ll.h"
struct replace_object {
struct oidmap_entry original;
struct object_id replacement;
};
void prepare_replace_object(struct repository *r);
/*
* This internal function is only declared here for the benefit of
* lookup_replace_object(). Please do not call it directly.
*/
const struct object_id *do_lookup_replace_object(struct repository *r,
const struct object_id *oid);
/*
* Some commands disable replace-refs unconditionally, and otherwise each
* repository could alter the core.useReplaceRefs config value.
*
* Return 1 if and only if all of the following are true:
*
* a. disable_replace_refs() has not been called.
* b. GIT_NO_REPLACE_OBJECTS is unset or zero.
* c. the given repository does not have core.useReplaceRefs=false.
*/
int replace_refs_enabled(struct repository *r);
/*
* If object sha1 should be replaced, return the replacement object's
* name (replaced recursively, if necessary). The return value is
* either sha1 or a pointer to a permanently-allocated value. When
* object replacement is suppressed, always return sha1.
replace-object: make replace operations thread-safe replace-object functions are very close to being thread-safe: the only current racy section is the lazy initialization at prepare_replace_object(). The following patches will protect some object reading operations to be called threaded, but before that, replace functions must be protected. To do so, add a mutex to struct raw_object_store and acquire it before lazy initializing the replace_map. This won't cause any noticeable performance drop as the mutex will no longer be used after the replace_map is initialized. Later, when the replace functions are called in parallel, thread debuggers might point our use of the added replace_map_initialized flag as a data race. However, as this boolean variable is initialized as false and it's only updated once, there's no real harm. It's perfectly fine if the value is updated right after a thread read it in replace-map.h:lookup_replace_object() (there'll only be a performance penalty for the affected threads at that moment). We could cease the debugger warning protecting the variable reading at the said function. However, this would negatively affect performance for all threads calling it, at any time, so it's not really worthy since the warning doesn't represent a real problem. Instead, to make sure we don't get false positives (at ThreadSanitizer, at least) an entry for the respective function is added to .tsan-suppressions. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16 03:39:52 +01:00
*
* Note: some thread debuggers might point a data race on the
* replace_map_initialized reading in this function. However, we know there's no
* problem in the value being updated by one thread right after another one read
* it here (and it should be written to only once, anyway).
*/
static inline const struct object_id *lookup_replace_object(struct repository *r,
const struct object_id *oid)
{
if (!replace_refs_enabled(r) ||
replace-object: make replace operations thread-safe replace-object functions are very close to being thread-safe: the only current racy section is the lazy initialization at prepare_replace_object(). The following patches will protect some object reading operations to be called threaded, but before that, replace functions must be protected. To do so, add a mutex to struct raw_object_store and acquire it before lazy initializing the replace_map. This won't cause any noticeable performance drop as the mutex will no longer be used after the replace_map is initialized. Later, when the replace functions are called in parallel, thread debuggers might point our use of the added replace_map_initialized flag as a data race. However, as this boolean variable is initialized as false and it's only updated once, there's no real harm. It's perfectly fine if the value is updated right after a thread read it in replace-map.h:lookup_replace_object() (there'll only be a performance penalty for the affected threads at that moment). We could cease the debugger warning protecting the variable reading at the said function. However, this would negatively affect performance for all threads calling it, at any time, so it's not really worthy since the warning doesn't represent a real problem. Instead, to make sure we don't get false positives (at ThreadSanitizer, at least) an entry for the respective function is added to .tsan-suppressions. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16 03:39:52 +01:00
(r->objects->replace_map_initialized &&
r->objects->replace_map->map.tablesize == 0))
return oid;
return do_lookup_replace_object(r, oid);
}
/*
* Some commands override config and environment settings for using
* replace references. Use this method to disable the setting and ensure
* those other settings will not override this choice. This applies
* globally to all in-process repositories.
*/
void disable_replace_refs(void);
#endif /* REPLACE_OBJECT_H */