You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Garrett Rooney <ro...@electricjellyfish.net> on 2008/04/15 01:14:08 UTC

Re: svn commit: r30594 - in branches/in-memory-cache/subversion: include libsvn_fs_fs libsvn_subr tests/libsvn_subr

On Mon, Apr 14, 2008 at 8:47 PM,  <gl...@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.

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.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r30594 - in branches/in-memory-cache/subversion: include libsvn_fs_fs libsvn_subr tests/libsvn_subr

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Mon, Apr 14, 2008 at 10:58 PM, David Glasser
<gl...@davidglasser.net> wrote:
> On Mon, Apr 14, 2008 at 6:14 PM, Garrett Rooney
>  <ro...@electricjellyfish.net> wrote:
>  > On Mon, Apr 14, 2008 at 8:47 PM,  <gl...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r30594 - in branches/in-memory-cache/subversion: include libsvn_fs_fs libsvn_subr tests/libsvn_subr

Posted by David Glasser <gl...@davidglasser.net>.
On Mon, Apr 14, 2008 at 6:14 PM, Garrett Rooney
<ro...@electricjellyfish.net> wrote:
> On Mon, Apr 14, 2008 at 8:47 PM,  <gl...@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.

>  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.

--dave


-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org