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

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.
[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.


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