Garrett Rooney wrote:
> 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...
Sorry I sort of ignored your last mail, I've been quite busy lately. But
it turns out that you guessed what worries me.
> 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...
The idea is that if you create an svn_fs_t in one thread, you must
always use it in that thread. I don't think we've spelled that out
anywhere, but then, we've not really defined our thread-safety
guarantees in general. Certainly a threaded svnserve uses svn_fs_t's in
the way that code expects them to be used.
I'm worried that it's possible to order svn_fs_t creation in such a way
that the gathered svn_error_t's are destroyed before the last svn_fs_t
that might want to use them. At this point, I don't even know if this
scenario is possible, much less how to recover from it.
> Have I mentioned that I'm not overly fond of thread local variables
> like this? Man do they make things confusing...
You don't say.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 30 20:31:56 2006