git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Jeff King <peff@peff.net>
Cc: Johannes Sixt <j6t@kdbg.org>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] git: add --no-optional-locks option
Date: Mon, 25 Sep 2017 11:51:31 -0700	[thread overview]
Message-ID: <CAGZ79kYOeJvQmw-h3GwFpv2w7AKtNWUxf96tUjPKPY1dMuzagA@mail.gmail.com> (raw)
In-Reply-To: <20170923033425.6ilykxl5pi7unlj6@sigill.intra.peff.net>

>> There might be another option to cope with the situation:
>>
>>  4. Teach all commands to spinlock / busywait shortly for important
>>      locks instead of giving up. In that case git-status rewriting
>>      the index ought to be fine?
>
> We do have all the infrastructure in place to do a reasonable busywait
> with backoff. I think the patch is roughly just:
>
> diff --git a/read-cache.c b/read-cache.c
> index 65f4fe8375..fc1ba122a3 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1563,7 +1563,8 @@ static int read_index_extension(struct index_state *istate,
>
>  int hold_locked_index(struct lock_file *lk, int lock_flags)
>  {
> -       return hold_lock_file_for_update(lk, get_index_file(), lock_flags);
> +       return hold_lock_file_for_update_timeout(lk, get_index_file(),
> +                                                lock_flags, 500);
>  }
>
>  int read_index(struct index_state *istate)
>
> though I think there are a few sites which manually call
> hold_lock_file_for_update() on the index that would need similar
> treatment.

uh, too bad. The patch above looks really promising, though. :)

>
> I suspect it would work OK in practice, unless your index is so big that
> 500ms isn't enough. The user may also see minor stalls when there's lock
> contention. I'm not sure how annoying that would be.

There is only one way to find out. Though we don't want to volunteer
all users into this experiment, I'd presume.

Regarding larger indexes, I wonder if we can adapt the 500ms
to the repo size. At first I thought the abbreviation length could be
a good proxy to determine the maximum waiting time, but now I am
not so sure any more.

Stefan

  reply	other threads:[~2017-09-25 18:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-21  4:32 [PATCH] git: add --no-optional-locks option Jeff King
2017-09-21  4:55 ` Junio C Hamano
2017-09-21  5:08   ` Jeff King
2017-09-21  5:29     ` Junio C Hamano
2017-09-21 18:25 ` Johannes Sixt
2017-09-22  4:25   ` Jeff King
2017-09-22 11:22     ` Jeff Hostetler
2017-09-22 15:04       ` Jeff King
2017-09-22 20:09     ` Stefan Beller
2017-09-22 21:25       ` Jeff King
2017-09-22 21:41         ` Stefan Beller
2017-09-23  3:34           ` Jeff King
2017-09-25 18:51             ` Stefan Beller [this message]
2017-09-27  6:44               ` Jeff King
2017-09-22  6:42 ` Daniel Santos
2017-09-22 16:04   ` Jeff King
2017-09-24 11:31 ` Kaartic Sivaraam
2017-09-25 16:17   ` Johannes Schindelin
2017-09-26 14:44     ` Jeff Hostetler
2017-09-25 16:10 ` Johannes Schindelin
2017-09-25 17:00   ` Jeff King
     [not found] ` <79ed4c34-1727-7c1e-868a-1206902638ad@gmail.com>
2017-09-27  6:40   ` Jeff King
2017-09-27 13:50     ` Kaartic Sivaraam
2017-09-27 16:28       ` Jeff King
2017-09-27  6:54 ` [PATCH v2] " Jeff King
2017-09-28 16:15   ` Johannes Schindelin

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=CAGZ79kYOeJvQmw-h3GwFpv2w7AKtNWUxf96tUjPKPY1dMuzagA@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=johannes.schindelin@gmx.de \
    --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.
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).