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

Re: svnserve pools and svn_fs_access_t

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-03-12 01:08:35 CET

[Summarizing some IRC discussions with ghudson.]

On Fri, 11 Mar 2005, Greg Hudson wrote:

> On Fri, 2005-03-11 at 17:55, Ben Collins-Sussman wrote:
> > I'm not sure how to fix this. Any suggestions from those who know
> > svnserve better? Lundblad, ghudson, etc.?
>
> A similar issue exists for the "user" field of the server baton
> structure. (I thought someone had fixed this, but apparently not, or
> perhaps only on the locking branch.)
>
Actually, you and I discussed this on IRC. Since we didn't have any
reports on it, I didn't consider it worth fixing on trunk, but instead
added a TODO about it for the locking branch. That's what sussman works on
right now, including the access_t stuff.

> The server baton should have a pool field. When authentication happens,
> the username should be allocated either in that pool or in a subpool,
> and the FS access object should be allocated similarly.
>
sussman: I and ghudson discussed this on IRC and we concluded that the
username should be allocated in the connection pool, and the access_t
should live in the command subpool despite what is being said above.

NOte to others: The access_t has to be destroyed after each command, since
it stores lock tokens that has to be forgotten. That's why we can't keep
it for the whole session.

> (Since in practice, authentication doesn't happen more than one or two
> times per connection, using a subpool might be overkill. But
> technically it's a memory leak not to do so.)
>
Since the username is only acquired once from the client, this is not a
problem.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 12 01:06:30 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.