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

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 
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 Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]