Re: [xml] Re: Thread-safety of XSLT contexts with shared dictionaries

[Daniel Veillard <veillard redhat com>]

On Fri, Jan 21, 2005 at 01:53:42PM +0000, Gary Coady wrote:
> Hi there,
> I was debugging an issue today where, under load, I would get a crash 
> (well, abort() due to double-free) like
> #5  0x081b9ded in xmlDictFree (dict=0x8762ec0) at dict.c:472
> #6  0x08192a0c in xmlFreeDoc (cur=0x8766158) at tree.c:1157
> #7  0x081c9bf5 in xsltFreeStylesheet (sheet=0x8766268) at xslt.c:495
>
> The program's usage of libxslt involves (potentially) many simultaneous 
> transformations using different XSLT contexts (xsltNewTransformContext). 
> Looking at the code, I felt that the most likely cause of this was the 
> sub-dictionaries used by XSLT (and yes it was).
>
> I don't know if you think this is a situation that is worth a patch 
> against; I can either place mutexes internally in libxml2, or around our 
> calls to create/destroy XSLT contexts. I don't really mind either way, 
> but this might help other people if they try something similar.
>
> Anyway, here is a suggested patch. I know that as written, xmlDictInit() 
> is not thread-safe - but the worst that can happen is a leaked mutex, 
> and I wanted to mirror the init/cleanup routines in the catalog code.

  Yup I knew about the potential problem, but it wasn't clear it would end
up being a serious one. I agree that the most generic solution is to
use mutexes to avoid race in the increment/decrement. I'm not sure however
that a global mutex is the best thing. One mutex per dict would avoid 
any initialization race and avoid a global contention point for all threads
while there really should not be global. It is a trade-off between:
   - cost of creating a mutex
 and
   - cost associated in being blocked on a global mutex

I would expect the cost of creating a mutex to be extremely low on
processors/arch with atomic test-and-set operations (and SMP cache
invalidation), on the other hand the cost of a global mutex rise quickly
precisely for the programs where threading is intensive and where that
mutex is really needed.
Any chance you could make another patch where the mutex is in the 
xmlDict structure and initialized in xmlDictCreate(). Also never put
a patch in the mail content dicrectly, add it as an attachment otherwise
the mail programs destroy it so much that patch(1) refuses to apply it.

  thanks,

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/