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 <[email protected]> wrote: > > On Wed, Sep 14, 2011 at 19:07, Julian Foad <[email protected]> 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 [1] > >> > >> "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?
