"Peter N. Lundblad" <peter@famlundblad.se> wrote on 08/13/2004 04:50:26
PM:
> 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.
Anything sounds better to me.
I do not know the function flow here, but if the client commands call the
conversion routines directly, couldn't a new set of conversion routines
just be made (copied). Those routines would make the assumption they are
using a single-thread environment and could safely cache the xlate handle
in the pool?
Obviously this would be ugly, and if the conversion routines are only
called from deeper in the library structure it would be impractical to do
it this way.
Mark
PS - I am working on an EBCDIC port (OS/400) and we have to call these
conversion routines everywhere.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
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:53:56 2004