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.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 14 16:41:25 2004