On Tue, 17 Aug 2004, Philip Martin wrote:
> "Peter N. Lundblad" <peter@famlundblad.se> writes:
>
> > - Have a global hash with mappings from handle name (identifying the
> > translation) to a linked list of xlate handles.
> > - When you want to translate:
> > . Lock a mutex.
> > . Look for a handle in the hash. If one is found, remove it from the list
> > and use it.
> > . If no handle was found, create one.
> > . Unlock the mutex
> > . Use the handle.
> > . Lock, put the handle back into the list and unlock.
>
> Just make sure you add/remove from the list without allocating memory,
> > This avoids having the lock held during the translation. It will create as
> > many handles as is needed simultaneously and destroy them at program
> > termination.
> >
> > It would be simpler to just have one handle per combination of to/from
> > encoding, but as Greg pointed out, this might give to much contention on
> > the translation lock, especially since we do a lot of translations during
> > our WC crawling commands.
>
> It's notoriously difficult to predict thread contention accurately.
> However, instinctively I prefer your other design, the one that
> provides per-thread xlate handles, assuming it can be implemented
> correctly.
>
OK. Here is the patch. It keeps the lock during apr_xlate_open, but that
call should be very rare compared to the number of translations we do. It
isn't ready yet, but quite so and I'd like feedback.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 24 22:39:32 2004