On Tue, Sep 23, 2014 at 12:31 PM, Stefan Fuhrmann <
stefan.fuhrmann_at_wandisco.com> wrote:
>
> On Thu, Sep 18, 2014 at 3:00 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>
>> On 11 September 2014 20:28, Stefan Fuhrmann
>> <stefan.fuhrmann_at_wandisco.com> wrote:
>> > On Wed, Sep 10, 2014 at 5:35 PM, Ivan Zhakov <ivan_at_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.
>
Received on 2014-10-20 14:35:01 CEST