Re: [xml] side effects of thread-enabling libxml2

[Daniel Veillard <veillard redhat com>]

On Fri, May 09, 2003 at 12:52:27PM +0200, Stéphane Bidoul wrote:
> Gary, Daniel,
>
> > My main concern is related to library maintainability. The 
> > code required to
> > make thread safe globals work is fairly complex already. The 
> > motivation
> > behind this code was to provide enough functionality to allow 
> > libxml2 to
> > get by until libxml3 came along. Trying to accomodate this 
> > request will make
> > the code more fragile, impact performance and maintainability.
>
> Fairly complex, indeed, I agree. 
> However, I'm not sure adding that small test on each
> global access will really make it more complex
> or impact performance.

  I did some profiling when switching thread compilation to be on
by default. For most operations the locking/unlocking does not
take up CPUs, unless you registered callbacks for node building registration
and destructions.

> > I don't think that this request to support a new feature 
> > (i.e. non-global
> > globals) should be supported, since it's already catered for 
> > by compiling
> > the library with threads=no.
>
> My use case (through the python bindings) is to set the globals 
> in the "main thread", and still benefit of the thread safety 
> feature(s) of libxml (i.e. the mutex in catalog.c).
> I need threads=yes for that mutex, but I don't need
> per-thread globals since they are never changed by
> the threads. 
 
   I still wonder if initializing the per thread variables from
the "global" values ain't the best approach, it allows to set up
the common environment for all threads a initialization time, and
if needed still allow to set up different per-threads defaults.
  This adds costs only at threads creation, and keeps the existing
code base except for one very limited point.

> Isn't it also a packaging and deployment problem? 
> On Linux, libxml2 is a shared package, and I started this discussion
> because I fear that my sysadmin will deploy libxml2 with-threads=yes,
> thereby changing the behaviour of my app.
>  
> Daniel's suggestion to initialize the per-thread globals from
> the values in the main thread would ensure unchanged behaviour
> for a non-thread-aware client. But, as he said, that would require 
> locking too if clients are allowed to change the globals when threads
> are running. Also, it would slightly change the behaviour
> (since the initial value of per thread globals would be different)
> -- however I don't think that behaviour is explicitly documented.

  Yep, still IMHO it's the cleanest solution.

Daniel

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