Re: [xml] initialization issues in libxml2

On Wed, May 21, 2008 at 4:56 PM, John Zolnowsky x69422/408-404-5064
<John Zolnowsky sun com> wrote:
From veillard redhat com Tue May 20 08:48:42 2008

On Tue, May 20, 2008 at 08:24:17AM -0700, John Zolnowsky x69422/408-404-5064 wrote:

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.

It's not a property of the loader, but of the threads implementation.
Both the Solaris threads and the POSIX pthreads models provides for
this, allowing/encouraging the use of multi-threading even when the
application is unaware of it.  Failure to provide the equivalent of
pthread_once() might be considered a deficiency in other threading

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).

The issue isn't multiple calls to xmlInitParser(), but rather
simultaneous initial calls.  In effect, the call from the .init section
would be satisfying the requirement to 'call xmlInitParser() in the
"main" thread before using any of the libxml2 API.'  Any later explicit
calls by the application or internal to libxml2 to xmlInitParser() will
find xmlParserInitialized already set and simply return.

Perhaps I misunderstood your concern.  Are you worried about the
porting of applications and libraries using libxml2 from
Solaris/OpenSolaris to other platforms with more limited threading

Why don't use some sort of "atomic compare and exchange" for setiing
and checking xmlParserInitialized state just at beginning of

Something like (in terms of Glib atomic operations)

gboolean need_init;
need_init =
    g_atomic_int_compare_and_exchange(&xmlParserInitialized, 0, 1);
if (!need_init)
/* regular initialization code ... */

Andrew W. Nosenko <andrew w nosenko gmail com>

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