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

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

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

Ok. 

>   This adds costs only at threads creation, and keeps the existing
> code base except for one very limited point.

Can you elaborate a bit what additional costs you foresee?

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

Okay. That solves the problem indeed, and does not look hard to do.
Shall I give it a try? 

And once that is done, I plan to experiment with thread-enabling
the python bindings (by releasing the global interpreter lock).

-sbi