9front - general discussion about 9front
 help / color / mirror / Atom feed
From: ori@eigenstate.org
To: 9front@9front.org
Subject: Re: [9front] git/fetch: be more robust
Date: Sun, 25 Jul 2021 21:42:31 -0400	[thread overview]
Message-ID: <02FEF4119D2B7885F94C9503DC06C2D6@eigenstate.org> (raw)
In-Reply-To: <0C78F8861F62859962D0700334F86680@felloff.net>

Quoth cinap_lenrek@felloff.net:
> so this is like a race condition?
> 
> depending how fast the reader is able to process the message?
> 
> the other side of the pipeline is reading the hash and then fails to locate
> it in git/fs because it has not been indexed yet when it reads too fast?

Kind of.

git/pull consumes the output of git/fetch, and
uses it to update the refs. The problem is that
we can consume the output of git/fetch and update
the refs, then *fail* to update the repo.

For some reason, it's never bitten me (fast internet,
small deltas when I pull), but it makes me uneasy
that we *can* write invalid refs.

> is this just a theory or is there proof that the problem is
> well understood?
> 
>  		if(hparse(&want[nref], sp[0]) == -1)
>  			sysfatal("invalid hash %s", sp[0]);
> -		if (resolveremote(&have[nref], sp[1]) == -1)
> +		if (resolveremote(&have[nref], ref[nref]) == -1)
>  			memset(&have[nref], 0, sizeof(have[nref]));
> -		print("remote %s %H local %H\n", sp[1], want[nref], have[nref]);
>  		nref++;
> 
> 
> wouldnt it be better to just estrdup() at the print(), then it seems
> cleaner and makes the diff smaller... like:
> 
> 		if (resolveremote(&have[nref], sp[1]) == -1)
>  			memset(&have[nref], 0, sizeof(have[nref]));
> -		print("remote %s %H local %H\n", sp[1], want[nref], have[nref]);
> +		ref[nref] = estrdup(sp[1]);
> 		nref++

Yeah, that's equivalent, and I've got no
preference. Updated patch attached, with
a fix for '-l':

--- //.git/fs/object/28f76455d39d990b47c6e46e18158f0a9ba09d25/tree/sys/src/cmd/git/fetch.c
+++ sys/src/cmd/git/fetch.c
@@ -181,7 +181,7 @@
 fetchpack(Conn *c)
 {
 	char buf[Pktmax], *sp[3];
-	char *packtmp, *idxtmp;
+	char *packtmp, *idxtmp, **ref;
 	Hash h, *have, *want;
 	int nref, refsz, first;
 	int i, n, req, pfd;
@@ -193,6 +193,7 @@
 	first = 1;
 	have = eamalloc(refsz, sizeof(have[0]));
 	want = eamalloc(refsz, sizeof(want[0]));
+	ref = eamalloc(refsz, sizeof(ref[0]));
 	while(1){
 		n = readpkt(c, buf, sizeof(buf));
 		if(n == -1)
@@ -213,19 +214,20 @@
 			continue;
 		if(refsz == nref + 1){
 			refsz *= 2;
-			have = erealloc(have, refsz * sizeof(have[0]));
-			want = erealloc(want, refsz * sizeof(want[0]));
+			have = earealloc(have, refsz, sizeof(have[0]));
+			want = earealloc(want, refsz, sizeof(want[0]));
+			ref = earealloc(ref, refsz, sizeof(ref[0]));
 		}
 		if(hparse(&want[nref], sp[0]) == -1)
 			sysfatal("invalid hash %s", sp[0]);
 		if (resolveremote(&have[nref], sp[1]) == -1)
 			memset(&have[nref], 0, sizeof(have[nref]));
-		print("remote %s %H local %H\n", sp[1], want[nref], have[nref]);
+		ref[nref] = estrdup(sp[1]);
 		nref++;
 	}
 	if(listonly){
 		flushpkt(c);
-		return 0;
+		goto showrefs;
 	}
 
 	if(writephase(c) == -1)
@@ -295,6 +297,15 @@
 		fail(packtmp, idxtmp, "could not index fetched pack: %r");
 	if(rename(packtmp, idxtmp, h) == -1)
 		fail(packtmp, idxtmp, "could not rename indexed pack: %r");
+
+showrefs:
+	for(i = 0; i < nref; i++){
+		print("remote %s %H local %H\n", ref[i], want[i], have[i]);
+		free(ref[i]);
+	}
+	free(ref);
+	free(want);
+	free(have);
 	return 0;
 }
 


      reply	other threads:[~2021-07-26  1:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26  0:23 ori
2021-07-26  0:36 ` [9front] " Anthony Martin
2021-07-26  1:39   ` ori
2021-07-26  0:45 ` [9front] " cinap_lenrek
2021-07-26  1:42   ` ori [this message]

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=02FEF4119D2B7885F94C9503DC06C2D6@eigenstate.org \
    --to=ori@eigenstate.org \
    --cc=9front@9front.org \
    /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 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 NNTP newsgroup(s).