Re: named_atomic tests failures on Windows

[Stefan Fuhrmann <st...@wandisco.com>]

On Tue, Sep 23, 2014 at 12:31 PM, Stefan Fuhrmann <
stefan.fuhrmann@wandisco.com> wrote:

>
> On Thu, Sep 18, 2014 at 3:00 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>
>> On 11 September 2014 20:28, Stefan Fuhrmann
>> <st...@wandisco.com> wrote:
>> > On Wed, Sep 10, 2014 at 5:35 PM, Ivan Zhakov <iv...@visualsvn.com>
>> wrote:
>>
> >> 2. Remove it since "named atomics" framework is only used for currently
>> >>    disabled revprop caching.
>> >
>> >
>> > ... I'm +1 on getting rid of the SHM code altogether (we are using MMAP
>> to
>> > get shared memory). It turned out to be a poor choice as all sorts of
>> > Windows
>> > platform specifics make it hard caused us to deviate further and further
>> > from
>> > the initial APR-based design. Some of the Windows-specific issues, e.g.
>> the
>> > file retry races in the init code, should have been reported before the
>> > 1.8.0
>> > release.
>> >
>> >>
>> >> Personally I don't see reason to spend resources fixing unused code,
>> >> especially
>> >> that even code on 'revprop-caching-ng' branch removes it also. Any
>> >> other opinions?
>> >
>> >
>> > No, I agree.
>> >
>> > The revpro-caching-ng branch pretty much exactly removes the SHM
>> > code.
>> I think that the revprop-caching-ng branch should not be merged. So
>> may be worth to remove named-atomics and SHM code from trunk to turn
>> the trunk back to the normal state (without unused and not working code)
>>
>
> Here is what I will do on /trunk:
>
> * Merge the new revprop caching scheme to FSX.
>

Done in r1632907,-9.

* Remove the SHM-dependent bits from FSFS but keep the actual
>   cache invocations (no-ops since there is no cache instance) at least
>   for now.
>

Done in r1632926.

 * Remove the named_atomics code.
>

Done in r1632936.


> * Update the revprop-caching-ng branch
>

Done in r1632945.


> Why do you think the revprop-caching-ng branch should not be merged?
>
> -- Stefan^2.
>