On Mon, Apr 14, 2008 at 10:58 PM, David Glasser
<glasser_at_davidglasser.net> wrote:
> On Mon, Apr 14, 2008 at 6:14 PM, Garrett Rooney
> <rooneg_at_electricjellyfish.net> wrote:
> > On Mon, Apr 14, 2008 at 8:47 PM, <glasser_at_tigris.org> wrote:
> > > Author: glasser
> > > Date: Mon Apr 14 17:47:45 2008
> > > New Revision: 30594
> > >
> > > Log:
> > > On the in-memory-cache branch:
> > >
> > > Conditional APIs and code that uses apr_memcache_t on
> > > SVN_HAVE_MEMCACHE.
> > >
> > > * subversion/include/svn_cache.h
> > > Add a warning that svn_private_config must be included before this
> > > file. (I'm not 100% clear on how this will work for external uses
> > > of the API.)
> > > Conditionalize inclusion of apr_memcache.h,
> > > svn_cache_create_memcache, and svn_cache_make_memcache_from_config
> > > on SVN_HAVE_MEMCACHE.
> >
> > You could make the symbols still exist in the no-memcache case, and
> > just return APR_ENOIMPL or something like that. Then fall back from
> > memcache to a local in memory cache in that case. The runtime hit
> > shouldn't be too bad, as you'll only be doing it at cache creation
> > time.
>
> Well, at the user level this is what happens; the only way to get
> memcache code to run is if you explicitly configure it. I started
> trying to do something like what you said, but the main problem was
> the apr_memcache_t type.
That's unfortunate...
> > Otherwise, I think the best option is moving svn_cache.h to
> > include/private or something like that, and just not exposing it at
> > all, since svn_private_config.h isn't exactly something a user of the
> > API can be expected to include.
>
> That might be a good idea. My other idea was to make a trivial
> svn_memcache_t wrapper type, so that nothing but the actual
> cache-memcache.c needs to know about the apr_memcache API.
Certainly an option. Shouldn't be all that much code, I imagine, as
it'd just be a pass through to the underlying APR functions.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-15 05:14:56 CEST