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

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

Daniel Veillard wrote:

> > 1. should I  attempt to change the python bindings so the globals in
> > there are also created per-threads (not a pleasant perspective).
> >    
>
>  I think that the per thread property of the global variables is a
> feature, that functionality should be preserved. What it means is
> that the current API now lack the possibility to setup the global
> default values. I think going back is not the way to go, going forward
> is. 
Agreed.

> Basically what you're asking for is the possibility to set up
> the global variable default used to initialize the values inherited
> from new threads, and that would be sufficient, right ? I doubt you
> actually want to change the global variable dynamically in the 
> various threads running at a given point in time.
>  Seems to me that making the affectation in the "main thread" is one
> way to do this. The other option is to generate xmlSetGlobalXXX()
> funtions, which should be realtively easy to do within globals.c
>
>  
The concept of "main thread" is unclear to me (running being mod_python 
and apache,
I don't control thread creation). Is the main thread the one that loads 
the library,
or the first one calling into libxml? [the patch I proposed to for win32 
threads
assume it's the thread loading the library]
And currently, per-thread globals don't inherit the values set in the 
main thread.
What do you think of a flag controlling the use of per-thread globals at 
run-time?
It could be something like xmlSet/GetPerThreadGlobalsEnabled();
And entries in global.c could read like

#undef    xmlGenericError
xmlGenericErrorFunc *
__xmlGenericError(void) {
   if (!perThreadGlobalsEnabled || IS_MAIN_THREAD)
   return (&xmlGenericError);
   else
   return (&xmlGetGlobalState()->xmlGenericError);
}

-sbi