Re: svn commit: r1331763 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.h fs_fs.c

[Stefan Fuhrmann <eq...@web.de>]

Am 30.04.2012 21:20, schrieb Greg Stein:
> On Sun, Apr 29, 2012 at 08:15, Stefan Fuhrmann<eq...@web.de>  wrote:
>> ...
>> The problem is that there is globally available file name
>> to back the SHM implementation on OSes that need it.
>> We can only assume write access to some file within the
>> respective repositories.
>>
>> Because a given server process may access thousands of
>> repositories during its lifetime, keeping the SHM data
>> alive for all of them is not an option, too.
>>
>> So, we store the new revprop generation as part of each
>> setrevprop call, i.e. this write will be serialized and the
>> write order be kept by the repository write lock.
>>
>> The only racy situation occurs when the data is being read
>> again but the first one to finish that procedure is guaranteed
>> to be the only one that initializes the SHM data. Since even
>> writers will first go through that initialization phase, they
>> will never operate on stale data.
> Is all the above written into some comments or docstrings? It would be
> nice to preserve information in the code rather than mailing lists :-)

Added to docstrings in r1345872.

-- Stefan^2.

Re: svn commit: r1331763 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.h fs_fs.c

[Greg Stein <gs...@gmail.com>]

On Jun 4, 2012 5:38 AM, "Stefan Fuhrmann" <eq...@web.de> wrote:
>
> Am 30.04.2012 21:20, schrieb Greg Stein:
>
>> On Sun, Apr 29, 2012 at 08:15, Stefan Fuhrmann<eq...@web.de>  wrote:
>>>
>>> ...
>>> The problem is that there is globally available file name
>>> to back the SHM implementation on OSes that need it.
>>> We can only assume write access to some file within the
>>> respective repositories.
>>>
>>> Because a given server process may access thousands of
>>> repositories during its lifetime, keeping the SHM data
>>> alive for all of them is not an option, too.
>>>
>>> So, we store the new revprop generation as part of each
>>> setrevprop call, i.e. this write will be serialized and the
>>> write order be kept by the repository write lock.
>>>
>>> The only racy situation occurs when the data is being read
>>> again but the first one to finish that procedure is guaranteed
>>> to be the only one that initializes the SHM data. Since even
>>> writers will first go through that initialization phase, they
>>> will never operate on stale data.
>>
>> Is all the above written into some comments or docstrings? It would be
>> nice to preserve information in the code rather than mailing lists :-)
>
>
> Added to docstrings in r1345872.

Cool. Thanks!