Daniel,
I was not aware of this requirement on libxml2 thread safety.
In Solaris, libraries mediating access to global data use static
initializers for the library-specific synchronization objects. This
allows use of the library by multiple other libraries without requiring
application knowledge of the lower-level library. For instance, in our
daemon, libxml2 is a third-level library being used to read
configuration information for a second-level library. The application
is using a thread-safe first level library, and is unaware of the
second level-library or libxml2. Likewise, the first-level library is
unaware of the the second-level library's use of libxml2. For
applications using multiple libraries, each of which might be invoking
libxml2 for configuration unbeknownst to the application, there is no
obvious location for the preliminary call to xmlInitParser().
While I would urge you to relax this limitation on libxml2's thread
safety, I don't really know how feasible that would be for other
(non-pthread) threading models. For our immediate needs for libxml2 in
Solaris, I expect we can provide a .init section invoking
xmlInitParser() and discourage the use of xmlCleanupParser() in
libraries and multi-threaded applications.
Thanks -JZ
> From [EMAIL PROTECTED] Tue May 20 00:36:54 2008
>
> On Tue, May 20, 2008 at 03:34:48PM +1200, Laszlo (Laca) Peter wrote:
> > Just wanted to add that we're using 2.6.31.
>
> Have you read http://xmlsoft.org/threads.html
> "call xmlInitParser() in the "main" thread before using any of the libxml2
> API"
>
> So right, there is no protection against multiple concurrent initialization
> calls. That's on purpose based on that rule and to avoid tons of troubles
> at initialization time.
> If your problem still persists after the xmlInitParser() call then I'm
> open to suggestions, after a clear analysis of the problem.
>
> thanks,
>
> Daniel
>
> >
> > On Mon, 2008-05-19 at 13:05 -0700, John Zolnowsky x69422/408-404-5064
> > wrote:
> > > We've recently observed a daemon hung in libxml2.
> > >
> > > Analysis of the core file showed that multiple threads had been
> > > through globals.c:xmlInitGlobals().
> > >
> > > I found two problems in the initialization routines of libxml2.
> > >
> > > 1) In globals.c, the initialization of xmlThrDefMutex is not protected
> > > against multiple threads simultaneously calling
> > > xmlInitializeGlobalState(), or repeatedly calling xmlInitGlobals().
> > >
> > > 2) In parser.c, the routine xmlInitParser() checks a static variable
> > > outside any lock, performs multiple initializations, then sets the
> > > static to indicate no further initializations.
> > >
> > > With the conversion of all Solaris libraries to default to lazyload,
> > > there would be a tendency for multiple threads to be synchronized at
> > > their first call to libxml2, resulting in multiple threads being able
> > > to enter these initialization routines nearly simultaneously. This
> > > would cause redundant initializations, which in the case of
> > > xmlInitGlobals(), would cause the creation of xmlMutex'es and trashing
> > > of previous values of xmlThrDefMutex. In the case captured in the
> > > corefile, apparently thread2 locked valueA of xmlThrDefMutex, thread3
> > > blocked on valueA, some other thread4 now called xmlInitGlobals()
> > > creating valueB, and finally thread2 released the unowned valueB,
> > > leaving thread3 hung forever.
> > >
> > > All initialization routines in libxml2 should be checked for inadequate
> > > static guards. Correction of these problems will require some
> > > structural changes to globals.c and parser.c, similar to the code
> > > wrapping xmlOnceInit() in threads.c
> > >
> > > Thanks -JZ
> >
> > _______________________________________________
> > xml mailing list, project page http://xmlsoft.org/
> > [email protected]
> > http://mail.gnome.org/mailman/listinfo/xml
>
> --
> Red Hat Virtualization group http://redhat.com/virtualization/
> Daniel Veillard | virtualization library http://libvirt.org/
> [EMAIL PROTECTED] | 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/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml
