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

[Gary Pennington sun com]

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.

Gary

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 
> > threads
> > 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
>      xmlInitializeGlobalState()
> 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 
> > 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);
> > }
>
>   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
>
> -- 
> Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
> veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
> _______________________________________________
> xml mailing list, project page  http://xmlsoft.org/
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml

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