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.
>
Then you won't get the optimization. NOte that we can still cache the
handle in the pool that was passed to the conversion function regardless
of where it was created. I don't think it is safe to use a pool in
different threads at the same time.
//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:19:31 2004