David Glasser wrote:
> On Fri, Mar 7, 2008 at 3:48 PM, Blair Zajac <blair_at_orcaware.com> wrote:
>> glasser_at_tigris.org wrote:
>> > Author: glasser
>> > Date: Fri Mar 7 10:23:54 2008
>> > New Revision: 29773
>> >
>> > Log:
>> > On the in-memory-cache branch:
>> >
>> > * README.branch
>> > Add a README, including a basic outline of the API I'm going to add
>> > and the implementation it's going to use.
>> >
>> >
>> > Added:
>> > branches/in-memory-cache/README.branch
>> >
>> > Added: branches/in-memory-cache/README.branch
>> > URL: http://svn.collab.net/viewvc/svn/branches/in-memory-cache/README.branch?pathrev=29773
>> > ==============================================================================
>> > --- (empty file)
>> > +++ branches/in-memory-cache/README.branch Fri Mar 7 10:23:54 2008
>> > @@ -0,0 +1,102 @@
>> > +This branch adds a simple in-memory cache library that handles
>> > +annoying memory-management details for you. FSFS has several
>> > +hand-written caches already; this will reduce duplicate code and make
>> > +it easier to add more.
>> > +
>> > +NULL is a legitimate value. There is no cache_delete (but you can set
>> > +to NULL, which may be good enough).
>>
>> It seems that any cache would want a cache_delete method. I've written a server
>> that exposes svn via Ice and it would be handy to have a cache.
>
> When we need it, sure. FSFS does have one bit of cache invalidation.
>
> However, the whole reason that this data structure is needed at all is
> that with APR pools, "deleting" (freeing memory) is non-trivial.
>
>> What about adding some fields in the structures to make an LRU cache possible
>> such as adding to the cache_entry the last time it was looked up. I guess one
>> could also wrap the value in another value that has those fields, so leaving
>> this alone would be good.
>
> The plan as designed is already LRU (though at the "page" level of
> granularity). If items_per_page=1 then this is a normal LRU cache,
> but then you have the overhead of one pool (at least 8K) per item...
>
>> But I think you'll always want a way of removing entries.
>
> Not for some of the actual applications I am planning this for. There
> are so many low-hanging trees of immutable but uncached data in
> FSFS...
>
> --dave
OK. Great, that takes care of my concerns.
What about thread safety? Are you going to address that?
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-08 01:22:20 CET