Yeah, we should be using the fsfs writelock for that work, shouldn't we?
On 2/12/07, David Glasser <glasser@mit.edu> wrote:
> On 2/12/07, Chia-liang Kao <clkao@clkao.org> wrote:
> > While trying to see how to have fs->change_rev_prop_if_value_is() implemented
> > for better atomicity, I saw something interesting in the related code.
> >
> > In libsvn_fs_fs/revs-txns.c: svn_fs_fs__change_rev_prop, the __set_rev_prop
> > called is loading the revision proplist hash, changing the value for what is
> > requested, and writing back the whole hash as the new proplist. The code is
> > vulnerable for race condition when two clients are setting different revision
> > properties on the same revision at the same time.
>
> Taking a look at the same code, I agree with CL that this is a race
> condition. While of course revprops are unversioned and we shouldn't
> be too worried about two clients changing the same revprop at the same
> time, if two clients try to change *different* revprops on the same
> revision at the same time it looks like you could lose one change.
>
> --dave
>
> --
> David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 12 17:52:21 2007