On Fri, Mar 7, 2008 at 4:22 PM, Blair Zajac <blair_at_orcaware.com> wrote:
> 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?
Good point. Options:
* Not thread safe at all. Caller must do mutexes.
* Always thread safe (if APR_HAS_THREADS).
* Boolean to constructor.
David Glasser | email@example.com | http://www.davidglasser.net/
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:32:21 CET