git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] git: add --no-optional-locks option

From
Jeff King <peff@peff.net>
Date
Sep 27, 2017, 06:44 UTC
Message-ID
<20170927064423.twluii6jj57hyk5y@sigill.intra.peff.net>
In-Reply-To
<CAGZ79kYOeJvQmw-h3GwFpv2w7AKtNWUxf96tUjPKPY1dMuzagA@mail.gmail.com>
On Mon, Sep 25, 2017 at 11:51:31AM -0700, Stefan Beller wrote:
Show 20 quoted lines
> > 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. :)

There are probably only a handful of other callers, and they'd just need to swap out s/update/&_timeout/. So it really is pretty trivial.

Show 6 quoted lines
> > 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.

Yes. One of the nice things about the optional-locks approach is that it only affects callers who specify the option. And the general idea has gotten a year of testing in Visual Studio, which makes me feel good about it.

> 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.
I think madness that way lies.
-Peff
Previous: Stefan BellerNext: Daniel Santos
Message 14 of 26 in “git: add --no-optional-locks option”
  1. git: add --no-optional-locks optionJeff King, Sep 21, 2017
  2. Junio C HamanoSep 21, 2017
  3. Jeff KingSep 21, 2017
  4. Junio C HamanoSep 21, 2017
  5. Johannes SixtSep 21, 2017
  6. Jeff KingSep 22, 2017
  7. Jeff HostetlerSep 22, 2017
  8. Jeff KingSep 22, 2017
  9. Stefan BellerSep 22, 2017
  10. Jeff KingSep 22, 2017
  11. Stefan BellerSep 22, 2017
  12. Jeff KingSep 23, 2017
  13. Stefan BellerSep 25, 2017
  14. Jeff KingSep 27, 2017
  15. Daniel SantosSep 22, 2017
  16. Jeff KingSep 22, 2017
  17. Kaartic SivaraamSep 24, 2017
  18. Johannes SchindelinSep 25, 2017
  19. Jeff HostetlerSep 26, 2017
  20. Johannes SchindelinSep 25, 2017
  21. Jeff KingSep 25, 2017
  22. git: add --no-optional-locks optionJeff King, Sep 27, 2017
  23. Johannes SchindelinSep 28, 2017
  24. Jeff KingSep 27, 2017
  25. Kaartic SivaraamSep 27, 2017
  26. Jeff KingSep 27, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.