Garrett Rooney wrote:
> On 8/2/06, Branko Čibej <brane@xbc.nu> wrote:
>> Garrett Rooney wrote:
>> > On 8/2/06, Branko Čibej <brane@xbc.nu> wrote:
>> >
>> >> 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.
>> >
>> > Yes, libsvn_fs was unloaded as a result of libsvn_ra_local being
>> > unloaded. I think we're still ok though, since the global pool we now
>> > create within libsvn_fs has to be created before the one in
>> > libsvn_fs_base, and since pools are destroyed in reverse order that
>> > means the global env cache will be destroyed before the global pool in
>> > libsvn_fs that results in the unloading of libsvn_fs_base...
>> >
>> > Or am I missing something here?
>> Yes ... the last svn_fs_t's pool can still be destroyed, and the
>> svn_fs_t's pool cleanups -- which need the BDB env handle -- called
>> after the DSO is unloaded. Also, the RA loader has no effect on when the
>> FS DSO is loaded in, e.g., svnserve.
>>
>> One probable scenario, using ra_local:
>>
>> 1. the client will create its working pool; that pool's parent is the
>> global pool
>> 2. the RA loader creates its DSO cache, in another (new) global pool
>> 3. the RA layer calls svn_fs_open/create, passing in the client's
>> working pool, returning an svn_fs_t
>> 4. the FS loader loads the FS backend; things happen, and eventually
>> the BDB environment cache is created in another global pool
>>
>> Upon apr_terminate, the FS DSO will be unloaded, then the RA DSO, then
>> the client's working pool that runs svn_fs_t's cleanups. BANG!
>>
>> A similar thing can happen in svnserve, except that there's no RA loader
>> in the way:
>>
>> 1. svnserve creates a request pool for the current request, whose
>> parent is a global pool
>> 2. svnserve calls svn_fs_open/create
>> 3. the FS loader loads the FS backend, things happen, etc.
>>
>> Upon apr_terminate, we hear a very similar and quite as loud a BANG!
>>
>>
>> Frankly I see no way around this short of insuring that the DSO cache's
>> pool is created before the global pool that's the parent for any pool
>> used by svn_fs_t's.
>
> I think we've made a best effort attempt here, and it's about the most
> we can do without requiring an initialization function that the user
> calls before creating any other pools.
Exactly. That's why I propose we disable DSO loading for RA/FS; I don't
see how we can do it right without breaking API compatibility.
> Another alternative might be moving the code that needs to run in pool
> cleanups outside of loadable DSOs. That might be reasonable if
> they're very small functions that only access data allocated on the
> heap, not any globals that live in the DSOs. We could stick them in
> libsvn_subr or something... Thoughts? I haven't really thought this
> through all the way yet, but does anyone think this is an idea worth
> pursuing?
Heh, you just proposed what I proposed. :)
Basically, for the BDB back-end, we're talking about a significant part
of the code. Not to mention that doing this would violate the layering.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 3 03:54:48 2006