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

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.

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.

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.


PS I can think of ways of accomodating this behaviour, but I don't like
any of them. I really don't like the suggestion below because, as written,
it's not thread safe and adding the locking to make it thread safe would
have an unneccessary performance burden. I don't know how often global
variables are accessed when the code is executing but I suspect that for
some of them, e.g. xmlDefaultBufferSize, it's quite often.

PPS I also don't like it because I can't begin to imagine what kind of
application would like to dynamically change the nature of global variables
at run time.

On Sun, May 04, 2003 at 12:38:08PM -0400, Daniel Veillard wrote:
On Sun, May 04, 2003 at 06:05:21PM +0200, Stéphane Bidoul wrote:
Daniel Veillard wrote:
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 
assume it's the thread loading the library]

  It's the thread which initialized the library, right ...

And currently, per-thread globals don't inherit the values set in the 
main thread.

  Hum, right... maybe that should be changed, see
The problem then is that xmlInitializeGlobalState() should take
a lock if it's peeking in the main thread global variables I think.
What do you think of a flag controlling the use of per-thread globals at 
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);

  Sounds too heavy. I would prefer something per-variable, though
I understand that from your point of view it would garantee the same
behaviour at minimal costs. I'm not strongly sided, if other users of
the thread features could voice their concern/preferences this would
help ...


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine
xml mailing list, project page
xml gnome org

Gary Pennington
Solaris Kernel Development,
Sun Microsystems
Gary Pennington sun com

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