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

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

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);
   return (&xmlGetGlobalState()->xmlGenericError);


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