[darcs-devel] [darcs #128] Wishlist: darcs with-lock-held

[David Roundy]

On Tue, Dec 28, 2004 at 10:00:30PM +0100, Juliusz Chroboczek wrote:
> [sorry for the late reply, I'm only now catching up on two months of mail]
> 
> > >   darcs with-lock-held <command>
> 
> > Would you want this to just prevent darcs commands that *modify* the
> > repository, or also to prevent darcs commands that just *read* the
> > repository (e.g. pulling from it)?
> 
> Just the former.  I'm trying to read darcs repos in a way that's safe
> against concurrent updates.

Sounds fine to me.  Obviously it would go into the "very advanced" section
of the manual...

I think this should be pretty easy for you to do yourself... it's just a
command with a single call to system, right? I'd like the documentation to
have some sort of a reasonable example of how this could be safely used,
and when it would be necesary.  I imagine you'd use it on a repository that
might get pushed to any moment, for example when running a tape backup,
to make sure the backup got a consistent version of the repository?

> I don't see how read locks can be implemented, by the way: we might
> not have write access to the repository we're pulling from, e.g. if
> it's owned by a different user or being accessed over HTTP.

I think we can hold a read lock if we include an indexed lock file.  When
we take the lock, we increment it, and when we release the lock we
increment it again.  Readers first check that the lock is even, and fail if
it is odd.  Then when they are finished reading, they check that the lock
still has the same value, and if not, they fail--so this check has to
happen before the reader does anything "interesting".  It would be a bit of
a pain, but should be doable.

On the other hand, if/when we implement a content-hash-based file naming
scheme, there shouldn't ever be a case where a reader could accidentally
get a wrong version of a file, regardless of what "writing" commands are
simultaneously being performed.  The worst that could happen would be that
the reader could fail to download a file that was deleted.
-- 
David Roundy
http://www.darcs.net