Garrett Rooney wrote:
> On 8/1/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
>
>> Yeah, I suspect they probably should. Now that I know why the ra side
>> matters I can dive into abstracting this out with a clear conscience.
>>
>> Thanks for the sharp eyes Philip!
>
> Ok, I ended up with a slightly different approach that didn't require
> a change to the ra code. The only reason we hit problems when
> libsvn_fs is unloaded early (after being pulled in by DSO loading of
> libsvn_ra_local) was that we registered a pool cleanup in libsvn_fs's
> (now global) pool. The cleanup is nice to have (it's nice to NULL out
> those variables so they can't be used after the pool is cleared), but
> honestly, since this only happens during global pool destruction
> anyway I'm not convince it's of tremendous importance. The only case
> where a problem would show up is if someone is calling into svn_fs_foo
> functions during global cleanups, which seems to be a
> not-especially-good idea in the first place...
>
> Anyway, if people could look at r20932 and let me know what they think
> I'd appreciate it. I'll probably propose it for backport soon...
Wait, does that mean the thing crashed when the RA lib (that loads the
FS lib) was unloaded, not when the FS lib itself was unloaded? Thing is,
the svn_fs_t can still live longer than the DSO, I think, because its
ultimately global grandparent pool is created before the common pool and
dso cache.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 2 23:56:09 2006