Comment 10 for bug 507557

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gareth White wrote:
> Robert Collins wrote:
>> We need it when deleting content so that two processes don't try to
>> delete the same file at the same time.
>
> In that case, I wonder if we should also be doing the renaming within
> the lock too. Even if we skip renaming files that we find are already
> in "obsolete_packs", there's still a chance that two processes will try
> to rename a file at the same time. It will have to either ignore
> NoSuchFile when renaming or do it within a lock too.
>

So actually, we could probably do a bit better.

Specifically, I think that at the time we go to obsolete the existing
packs, we would actually know that the packs are no longer referenced by
the repository. If I break down the timing...

1) Both repo A & B start an autopack, affecting files 1,2,3, trying to
   create a new file 4A and 4B respectively.
2) They finish reading all of 1,2,3 and write out 4A and 4B.
3) Repo A grabs the lock, and writes out that the new referenced list is
4A. Repo A succeeds, and starts moving 1, 2, 3 into the obsolete folder.
4) Repo B then grabs the lock and rereads pack-names. Finding that 1,2,3
are no longer referenced. However it still remembers that 1,2,3 became
4B. It writes out that the new pack-names should be 4A and 4B, and then
proceeds to try to rename 1,2,3.

I'm trying to decide between

5a) Repo B sees that 1,2,3 are no longer referenced, and thus removes
them from the 'to-be-rename-into-obsolete' list.

5b) Repo B tries to obsolete them anyway, but does not delete them from
obsolete packs.

The reason I question 5a is what the failure modes are. (If two clients
both try to obsolete certain files, but one of them gets interrupted,
then those files get left there indefinitely.)

Then again, there is a race condition with trusting
"list_dir('obsolete_packs')". Specifically, if Repo A has renamed 1 and
2, but not yet 3, then Repo B will list the directory, and find that it
still thinks 3 should be renamed. But before Repo B gets to it, Repo A
will have renamed it.

Anyway, I'm still sifting through it, but I think I've got some stuff
put together for this.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktXRRgACgkQJdeBCYSNAANFSgCcC0kKwGOGqHAeSjRIpz7IzXE0
VXgAnA7fUJh6zagxK905nzV0RFSxGcwW
=vrQ+
-----END PGP SIGNATURE-----