All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Andreas Krey" <a.krey@gmx.de>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Bryan Turner" <bturner@atlassian.com>,
	"Git Users" <git@vger.kernel.org>
Subject: Re: [PATCH] gc: run pre-detach operations under lock
Date: Wed, 12 Jul 2017 12:58:17 -0400	[thread overview]
Message-ID: <20170712165817.xcq4we5ynl3opm37@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqvamx1u3i.fsf@gitster.mtv.corp.google.com>

On Wed, Jul 12, 2017 at 09:46:25AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Instead, we can do something a bit simpler: take the lock
> > only for the duration of the pre-detach work, then detach,
> > then take it again for the post-detach work. Technically,
> > this means that the post-detach lock could lose to another
> > process doing pre-detach work. But in the long run this
> > works out.
> 
> You might have found this part gross, but I actually don't.  It
> looks like a reasonable practical compromise, and I tried to think
> of a scenario that this would do a wrong thing but I didn't---it is
> not like we carry information off-disk from the pre-detach to
> post-detach work to cause the latter make decisions on it, so this
> "split into two phrases" looks fairly safe.

Anytime I have to spend a few paragraphs saying "well, it looks like
this might behave terribly, but it doesn't because..." I get worried
that my analysis is missing a case. And that writing it in a way that
avoids that analysis might be safer, even if it's a little more work.

I gave it some more thought after sending the earlier message. And I
really think it's not "a little more work". Even if we decided to keep
the same file and replace the PID in it with the daemonized one, I think
that still isn't quite right. Because we don't do so atomically unless
we take gc.pid.lock again. But we may actually conflict with somebody
else on that! Even though that somebody would just pick up the lock,
read gc.pid and say "well, looks like somebody else is running" and
release it again. So we'd have to either hold the lock the whole time,
or do some kind of retry loop to race with other processes picking up
the lock.

It's definitely possible, but it's fighting an uphill battle against the
way our locking and tempfile code works. So I came to the conclusion
that it's not worth the trouble, and what I posted is probably a good
compromise.

-Peff

  reply	other threads:[~2017-07-12 16:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-04  7:57 Flurries of 'git reflog expire' Andreas Krey
2017-07-04  9:43 ` Ævar Arnfjörð Bjarmason
2017-07-06 13:27   ` Andreas Krey
2017-07-05  8:20 ` Jeff King
2017-07-06 13:31   ` Andreas Krey
2017-07-06 17:01     ` Bryan Turner
2017-07-11  4:45       ` Andreas Krey
2017-07-11  7:25         ` [BUG] detached auto-gc does not respect lock for 'reflog expire', was " Jeff King
2017-07-11  9:06           ` [PATCH] gc: run pre-detach operations under lock Jeff King
2017-07-12 16:46             ` Junio C Hamano
2017-07-12 16:58               ` Jeff King [this message]
2017-07-12 21:10                 ` Junio C Hamano
2017-07-11  7:35         ` Flurries of 'git reflog expire' Bryan Turner
2017-07-11  7:45           ` Jeff King
2017-07-11  7:31       ` 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=20170712165817.xcq4we5ynl3opm37@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=a.krey@gmx.de \
    --cc=bturner@atlassian.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    /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.