Re: svn commit: rev 1186 - trunk/subversion/bindings/ruby

On Wed, Feb 06, 2002 at 10:44:35AM +0900, Yoshiki Hayashi wrote:
> Greg Stein <gstein@lyra.org> writes:
> > > Author: yoshiki
> > > Date: 2002-02-05 13:24 GMT
> > > New Revision: 1186
> > >
> > > Modified:
> > > trunk/subversion/bindings/ruby/fs.c
> > > Log:
> > > * fs.c (free_fs): Do not call svn_fs_close_fs because it will toss pool fs is
> > > allocated. The pool might be also used by Svn::Repos object.
> >
> > How could the Svn::Repos object use a pool that is internal to the svn_fs
> > object? This doesn't make sense to me...
>
> It's other way around. Svn::Fs object is constructed out of
> the pool Svn::Repos is using. It happens when you call
> Svn::Repos#fs, which create Svn::Fs object by calling
> svn_repos_fs function.

That isn't quite correct. svn_fs_close_fs() only clears/destroys a subpool.
It will /not/ affect the pool that you passed in when you created the FS
object. It is perfectly safe to call close_fs().

> svn_repos_fs returns svn_fs_t * which lives in the same pool
> of svn_repos_t *.

No... the FS lives in a subpool. That subpool can be independently freed.

> Documentation of svn_repos_fs says
> nothing about the pool svn_fs_t is allocated but it is safer
> to assume they are using the same pool than they came from
> distinct pools.

Then the documentation should be updated. But even so, there isn't any way
that close_fs could "reach out" and kill somebody else's pool. It does (and
should) only affect its internal storage.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org