[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] RA sessions should always be loaded from the same pool

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-07-28 01:03:04 CEST

On Wed, 2005-07-27 at 23:27 +0100, Nix wrote:
> > I gave up trying to follow the auth stuff. However, at around line
> > 720 svn_ra_dav__open calls svn_auth_set_parameter and passes things
> > allocated from its pool and these get stored in the hash passed via
> > the callbacks argument, so it looks like the hash could well have a
> > longer lifetime than the dav session.

Yuck. Data stored within auth_baton should be allocated in the same
pool as auth_baton, according to our general philosophy, and there's no
elegant way to make that happen when the data being stored is a void
pointer. We could add a call to retrieve the auth baton's pool,

Failing that, cleaning up the parameters in a pool cleanup function
seems prudent. Like Philip, though, I'm a little lost as to how the
auth system works. Why is ra_dav responsible for auth parameters with
names that aren't clearly within an ra_dav namespace?

> > Interesting, what do you see as the advantage of --enable-dso?

Some of our package distributors use it to manage dependencies. By
moving mod_dav_svn into its own package, for instance, the core
Subversion package doesn't have to depend on httpd. Similarly for
libsvn_fs_base and Berkeley DB.

> Simply that I use svnserve a lot more than ra_dav, and my svn server
> is so small that keeping the number of shared libs loaded down counts
> (or at least it counted in the days before prelink).

I'm surprised that this would matter. Loading a shared library doesn't
necessitate actually reading in the whole thing from disk into memory,
although I suppose it does mean resolving from symbols.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 28 01:05:07 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.