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

["Stéphane Bidoul" <stephane bidoul softwareag com>]

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.
[my use case does not require locking - see below]
 
> 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. 

It's not thread safe if threads change the globals,
of course. But since libxml itself never changes the 
globals itself, it does not need
locking, assuming that client code sets the globals
in the main thread only. 

And that looks fairly easy to explain (it's already 
said in the documentation that the main thread must
call xmlInitParser before everything else, 
it would be easy to say the same is true
for globals if per-thread globals are disabled. 

> All libxml2 users who are implementing their own 
> threading/locking policy
> on top of libxml2 MUST ensure that the library is compiled 
> with threads=no.
> This is really just a documentation problem for users of the library.

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.

-sbi