[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.1rc1 performance regression in 'svn status' (and also 1.1rc2)

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-08-13 22:50:26 CEST

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.

> (assuming the threadid doesnt get re-used).
>
It won't be reused until the previous user is dead and then it can't be
the current thread.

I'll finish some other work and then work on this idea if a) no one kills
it (brane, you're good at such things:-) or b) someone else beats me to
it.

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 13 22:44:11 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.