On 6/30/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> So Brane's comment implies that maybe if bdb->pool is already NULL we
> shouldn't bother dealing with bdb->error_info, presumably since it's
> already been destroyed via apr_threadkey_private_delete. I'm not
> entirely sure this is correct though. We didn't register any
> destructor when we created the thread-local variable, so it won't have
> actually destroyed the errors. Do we have to put code clearing those
> errors into the cleanup_env function, so that if it's called before
> the __close code it can clean up the errors, then delete the thread
> local var? It'd also have to do the free(), I imagine... The __close
> code would then have to check for bdb->pool before it does the clear
> and free, right?
>
> Am I on the right track here? Anyone? This stuff is kind of voodoo,
> and I'm not all that clear that I'm even close to understanding the
> actual problem...
Another question that jumps to mind, how does this stuff even work
with thread local variables like this? Does it imply that __close
needs to be called from the same thread that was using the environment
(and thus that generated the errors) so that it can free the errors?
If that's the case, can cleanup_env even potentially destroy those
errors, how would it get at them? I feel like I'm missing something
here...
Have I mentioned that I'm not overly fond of thread local variables
like this? Man do they make things confusing...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 30 18:44:44 2006