On Sun, 15 Aug 2004, Travis P wrote:
> 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:
> >>>
> >>>>
> >> 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.
>
But apr_pool_userdata_{get,set} aren't thread-safe, so you can't use them
on the same pool in different threads simultanously.
Oh, had we only had init routines that were required to be called by the
user!
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 15 16:16:48 2004