From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, Johan Herland <johan@herland.net>,
Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
git@vger.kernel.org
Subject: Re: [PATCH v2 04/12] refs: implement simple transactions for the packed-refs file
Date: Thu, 20 Jun 2013 09:49:51 +0200 [thread overview]
Message-ID: <51C2B41F.2050708@alum.mit.edu> (raw)
In-Reply-To: <7vfvwdzz6k.fsf@alter.siamese.dyndns.org>
On 06/19/2013 09:18 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> Handle simple transactions for the packed-refs file at the
>> packed_ref_cache level via new functions lock_packed_refs(),
>> commit_packed_refs(), and rollback_packed_refs().
>>
>> Only allow the packed ref cache to be modified (via add_packed_ref())
>> while the packed refs file is locked.
>>
>> Change clone to add the new references within a transaction.
>>
>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>> ---
>> builtin/clone.c | 7 ++++-
>> refs.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++-----------
>> refs.h | 27 +++++++++++++++++--
>> 3 files changed, 98 insertions(+), 19 deletions(-)
>>
>> diff --git a/builtin/clone.c b/builtin/clone.c
>> index 66bff57..b0c000a 100644
>> --- a/builtin/clone.c
>> +++ b/builtin/clone.c
>> @@ -489,17 +489,22 @@ static struct ref *wanted_peer_refs(const struct ref *refs,
>> return local_refs;
>> }
>>
>> +static struct lock_file packed_refs_lock;
>> +
>> static void write_remote_refs(const struct ref *local_refs)
>> {
>> const struct ref *r;
>>
>> + lock_packed_refs(&packed_refs_lock, LOCK_DIE_ON_ERROR);
>> +
>> for (r = local_refs; r; r = r->next) {
>> if (!r->peer_ref)
>> continue;
>> add_packed_ref(r->peer_ref->name, r->old_sha1);
>> }
>>
>> - pack_refs(PACK_REFS_ALL);
>> + if (commit_packed_refs())
>> + die_errno("unable to overwrite old ref-pack file");
>> }
>
> The calling convention used here looks somewhat strange. You allow
> callers to specify which lock-file structure is used when locking,
> but when you are done, commit_packed_refs() does not take any
> parameter.
>
> lock_packed_refs() make the singleton in-core packed-ref-cache be
> aware of which lock it is under, so commit_packed_refs() does not
> need to be told (the singleton already knows what lockfile is in
> effect), so I am not saying the code is broken, though.
>
> Does the caller need to even have an access to this lock_file
> instance?
No it doesn't. My reasoning was as follows:
lock_file instances can never be freed, because they are added to a
linked list in the atexit handler but never removed. Therefore they
have to be allocated statically (or allocated dynamically then leaked).
[I just noticed that lock_ref_sha1_basic() leaks a struct lock_file
every time that it is called.]
I wanted to leave the way open to allow other packed refs caches to be
locked. But since all packed refs caches are allocated dynamically, the
lock_file instance cannot be part of struct packed_ref_cache. So I
thought that the easiest approach is to rely on the caller, who
presumably can know that only a finite number of locks are in use at
once, to supply a usable lock_file instance.
But currently only the main packed ref cache can be locked, so it would
be possible for lock_packed_refs() to use the static packlock instance
for locking. I will change it to do so.
If/when we add support for locking other packed ref caches, we can
change the API to use a caller-supplied lock_file. Or even better,
implement a way to remove a lock_file instance from the atexit list;
then lock_packed_refs() could use dynamically-allocated lock_file
instances without having to leak them.
v3 to come.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2013-06-20 7:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 7:51 [PATCH v2 00/12] Fix some reference-related races Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 01/12] repack_without_ref(): split list curation and entry writing Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 02/12] pack_refs(): split creation of packed refs " Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 03/12] refs: wrap the packed refs cache in a level of indirection Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 04/12] refs: implement simple transactions for the packed-refs file Michael Haggerty
2013-06-19 19:18 ` Junio C Hamano
2013-06-20 7:49 ` Michael Haggerty [this message]
2013-06-20 11:55 ` Jeff King
2013-06-20 18:03 ` Michael Haggerty
2013-06-20 19:55 ` Jeff King
2013-06-20 17:11 ` Junio C Hamano
2013-06-20 17:58 ` Michael Haggerty
2013-06-20 18:36 ` Junio C Hamano
2013-06-19 7:51 ` [PATCH v2 05/12] refs: manage lifetime of packed refs cache via reference counting Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 06/12] do_for_each_entry(): increment the packed refs cache refcount Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 07/12] packed_ref_cache: increment refcount when locked Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 08/12] Extract a struct stat_data from cache_entry Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 09/12] add a stat_validity struct Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 10/12] get_packed_ref_cache: reload packed-refs file when it changes Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 11/12] for_each_ref: load all loose refs before packed refs Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 12/12] refs: do not invalidate the packed-refs cache unnecessarily Michael Haggerty
2013-06-19 18:56 ` [PATCH v2 00/12] Fix some reference-related races Jeff King
2013-06-20 9:09 ` Michael Haggerty
2013-06-20 11:52 ` 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C2B41F.2050708@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 \
--cc=ramsay@ramsay1.demon.co.uk \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).