On Aug 14, 2004, at 9:54 AM, Peter N. Lundblad wrote:
> On Sat, 14 Aug 2004, Mark Benedetto King wrote:
>
>> On Fri, Aug 13, 2004 at 10:50:26PM +0200, Peter N. Lundblad wrote:
>>> On Fri, 13 Aug 2004, C.A.T.Magic wrote:
>>>
>>>>
>>>> Peter N. Lundblad wrote:
>>>>> This was discussed earlier on this thread. If a pools parent is in
>>>>> a
>>>>> different thread, this will not work. You can't use a xlate handle
>>>>> in
>>>>> different threads at the same time, AFAICK.
>>>>
>>>> maybe you can store store the threadID together with the xlate
>>>> handle,
>>>> and only use the pool's xlate handle if the threadIDs match?
>>>
>>> That requires locking, since another thread might be setting it
>>> during the
>>> test.
>>>
>>> But, what about the following approach:
>>> - When a pool is created in svn_pool_create(_ex), store the current
>>> apr_os_thread_t in the pool.
>>> - When we want an xlate handle, search the pool tre upwards until we
>>> are
>>> in a pool created by another thread or we find a handle. If the pool
>>> wasn't created by our routines, then we will detect that and stop.
>>>
>>
>> We don't tell people not to trade pools between threads, so just
>> because a pool was created by one thread doesn't mean it won't
>> be in use by another.
>>
> I think I see what you mean now:
> - T1: Create pool p1
> - T1: Create subpool of p1, p2
> - T1: start thread T2 and give it p1
> - T2: use p1 for char xlations
> - T1: use p2 for xlations, get cached xlate handle from p1 and use,
> kaboom!
>
> Sorry. I'll rethink again.
To defend against that scenario, as a slight variation of the "store
the current apr_os_thread_t in the pool" approach, what if rather than
store the thead id with by pool, store the id as part of the
cache-lookup id for the cached xlate handle. The thread-safety rule
then being: a thread can only use the xlate handle that it cached.
This may involve the cached handle not always being used and maybe
being re-looked up and cached independently. For the common case where
pools aren't handed around and multiple xlate handles are looked up in
the same thread (I'm assuming this is most common), then the cached
xlate handle will be readilty available.
(Disclaimer: I haven't programmed with APR pools nor used multilingual
libraries as Subversion is using. I've just been following the email
list. Apologies if I've the wrong ideas about what is possible in that
context.)
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 15 15:36:31 2004