On Tue, May 20, 2008 at 08:24:17AM -0700, John Zolnowsky x69422/408-404-5064 wrote: > 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().
Not having initialization routines for libraries and relying on the loader to do the initializations sounds a very specific model, I don't think you can expect that all the time. > 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. That sounds the wrong approach to me, because then portable code using libxml2 would have to initialize differently on Solaris than from other OSes. Think for example to all those Apache modules, that's just not possible. Maybe we can find a way to make sure xmlInitParser() is not used in a reentrant way (but since that's where all the thread specific data are initialized that sounds like a challenge, the trick of using the loader to bootstrap the sequence is unfortunately non portable and can't be relied upon IMHO). Daniel -- 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
