subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Martin <philip.mar...@wandisco.com>
Subject Re: svn commit: r1296604 - in /subversion/trunk/subversion/libsvn_fs_fs: caching.c fs.h fs_fs.c
Date Mon, 05 Mar 2012 11:27:34 GMT
Philip Martin <philip.martin@wandisco.com> writes:

> Daniel Shahaf <danielsh@elego.de> writes:
>
>>> What about atomic revprop changes?  I don't see what ensures that the
>>> old value read by change_rev_prop_body is the most up-to-date value.
>>> 
>>
>> ffd->revprop_generation is used as part of the cache key, the file is
>> written before the write-lock is released and read again as soon as the
>> write-lock is taken.  Do you see a problem?
>
> I'm worried about the case where the FS passed to
> svn_fs_fs__change_rev_prop has a cache that is already populated.  The
> values in the cache might be out-of-date because some other thread with
> another FS has written newer values.  It looks like change_rev_prop_body
> will examine the out-of-date cached value when doing the "atomic"
> update.

Maybe the threaded case is OK because there is only one cache?  What
about another process that changes the repository after the cache has
been populated?

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Mime
View raw message