Garrett Rooney wrote:
> On 6/7/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
>
>> Ok, so you might ask, why not just add that explicit destroy and move
>> on with life? Well, it's not quite so simple. You see, we shouldn't
>> actually have to do that. When you create a new top level pool (like
>> connection_pool) it gets registered as a child of the global pool,
>> which is destroyed during apr_terminate.
>>
>> You might think "ahh, it's just some weird behavior from APR's fork
>> code, it probably magically unregisters cleanups behind your back",
>> but, as far as I can tell it doesn't. apr_proc_fork() is about the
>> simplest wrapper around the underlying fork() call that you can think
>> of, and there are no magical atfork callbacks registered anywhere that
>> I can find.
>>
>> Now, I've hacked the pool creation code, so I can see that it's
>> getting linked into the global pool, and I've hacked the terminate
>> code, so I can see that apr_terminate is getting called in the child
>> process when it exits, but for some reason it never gets around to our
>> pool (I added an apr_pool_tag when we create the connection pool, and
>> I look for that tag in apr_pool_destroy, and we never hit it).
>>
>> Well, it's worse than that actually. It's not that we never hit it,
>> it's that we /almost/ never hit it. If I run the basic_tests.py then
>> my log file shows me that it actually gets cleaned up once, but that's
>> out of maybe 20 or so child processes that were spawned off, which is
>> not especially comforting.
>
> Ok, so I was misreading the log output. The pool is definately
> getting destroyed even in the case where there's an error, it's just
> that it doesn't seem to do any good unless it's an explicit
> destruction. Just letting global pool get destroyed doesn't seem to
> cut it. No clue why yet...
In pure ignorance, I ask:
Is there any chance there is an ordering problem?
Maybe whatever it is in BDB that is checking for proper
disconnection is running before the global pool gets
destroyed (and disconnects properly.)
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 7 19:10:13 2006