Hyrum K Wright wrote on Wed, Sep 14, 2011 at 16:13:41 -0500:
> On Wed, Sep 14, 2011 at 4:00 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> > On Wed, Sep 14, 2011 at 19:07, Julian Foad <julian.foad_at_wandisco.com> wrote:
> >> A patch in progress, for demonstration and your feedback.
> >> Since long ago we've thought about letting the client, through the
> >> libsvn_client API, share a single RA connection across a series of
> >> operations -- e.g.
> >> "svn update a b c" currently opens 3 RA sesssions.
> >> Similarly, inside libsvn_client we often open up an extra RA session
> >> when we could have re-used an old one -- e.g.
> >> Update with externals -- opens a new session per external 
> >> "svn mergeinfo" -- opens two or three sessions
> >> The attached patch implements "caching" of connections that have been
> >> used and may be used again. The cache is initialized (to empty) by the
> >> caller (the client executable) and connections in it are established or
> >> re-used by libsvn_client as required.
> > Hi Julian,
> > My original idea was to make ra session pool (cache) to be part of
> > svn_client_context_t, so callers of svn_client_* API do not have to be
> > modified. And pattern usage of this pool would by something like:
> > svn_ra_session_t * ra = svn_client__ra_pool_get_session(ctx, pool)
> > [perform some operations with RA session]
> > then call
> > svn_client_ra_pool_release_session(ctx, ra);
> > (RA session will be automatically released back to session pool
> > (cache) when pool used in svn_client__ra_pool_get_session() is
> > cleared)
> > What do you think?
> I'll note that we may not even need an explicit release function, as
> the current ra session infrastructure simply installs a pool cleanup
> hook to do proper shutdown. We could modify this hook to release the
> ra session back to the cache,
Do those pool cleanup handlers live in libsvn_client? If not, how could
they release the session to the cache?
Received on 2011-09-15 00:03:11 CEST