Re: [xml] thread safe?

[Gary Pennington <Gary Pennington uk sun com>]

Hi,

Apologies for the long answer, but it's a complex issue and there are certain
subtleties which need to be examined.

libxml and libxslt are not thread-aware. That means that unless you take special
precautions when linking with either library from a multi-threaded application,
things will go wrong.  Special precautions means, synchronizing access to the
library by your application threads in such a way that your various threads do
not interfere with each other. Also, even if you are extremely careful about
synchronizing access to this library, things may still go wrong if you have
other thread-unsafe libraries linked with your application (or if you use
thread-unsafe routines in your multi-threaded application - which I assume you
aren't).

I'll give you some examples of where things could go wrong (only examples, and
only libxml which I know better than libxslt) and you'll begin to see the full
picture.

libxml uses a number of global variables and access to these variables is not
synchronized between threads. A good example is
xmlDoValidityCheckingDefaultValue which should be set to 1 or 0 depending on
whether you want validity checking to happen by default or not. It would be very
possible for one thread to set this to 1, only to be pre-empted by a different
thread who sets it to 0 before the first thread gets another chance to execute.
This would lead to completely the wrong behaviour from your appliation to that
which you desired.

errno (discussed recently, see libxml archive) is a global variable from libc.
It is used in several places inside libxml and it's possible that the value of
errno is lost if you access libxml from a thread other than your main thread
(implementation dependant, but that's what happens on Solaris).

You can defend against this kind of  behaviour in a number of ways, but there it
is really difficult to be 100% safe.

As David indicated, only calling libxml from a single thread will mean you are
safe from many types of errors. But, unfortunately, not all. Many parts of the
standard C library do not work safely when used by threaded programs, for
instance strtok. These functions are updating global memory, i.e. a piece of
memory allocated from within libc. Generally speaking you have to replace the
thread unsafe function with the thread safe version, e.g. strtok_r, to get
thread-safe behaviour. I know that strtok is used inside libxml, so if David's
application used strtok in one thread whilst libxml was using it in a separate
thread, the application could break.

There are many examples of thread-unsafe functions inside the standard C
library, here is a snippet from the Solaris manpage which details them:

           The following table  contains  reentrant  counterparts
           for Unsafe functions.  This table is subject to change
           by Sun.

           Reentrant functions for libc:

           Unsafe Function               Reentrant counterpart
           ctime                         ctime_r
           localtime                     localtime_r
           asctime                       asctime_r
           gmtime                        gmtime_r
           ctermid                       ctermid_r
           getlogin                      getlogin_r
           rand                          rand_r
           readdir                       readdir_r
           strtok                        strtok_r
           tmpnam                        tmpnam_r


Some grepping through the libxml source seems to indicate that only localtime
and strtok are used from the above list and then only in certain configurations,
so it looks like libxml is not dependant on global state in libc on Solaris.
However, there may be unsafe functions being used from other libraries and this
list will vary by platform and library.

You could try to make access to libxml single threaded by synchronizing access
in such a fashion that only one thread at a time is ever active, even if it
isn't the same thread. This would buy you the same level of safety as only
accessing the library from the same thread, in other words - mostly safe but not
completely safe (unless you know you don't use these thread unsafe functions in
your code or any other libraries with which you link).

I hope that is enough detail to let you know what the issues are. Basically, you
can synchronize access to a thread-unsafe library and thus make individual
library invocations safe; but there is global memory out there which may be
being updated across function calls (and hence your synchronisation barriers)
and there is no way to make that safe especially when there are more
thread-unsafe libraries linked with your application.

Yours,

Gary


David Frascone wrote:

> I use libxml all the time in a threaded program, but, I never make concurrent
> calls.  (The actual code that calls libxml is a single thread of execution).
>
> I have absolutely no problems with it.
>
> -Dave
>
> On Tue, Jun 26, 2001 at 08:33:49AM -0400, Fred_Smith computrition com wrote:
> > Oh my. Here I've been operating under the belief that libxml is thread-safe
> > (I wonder where I got that idea).  Can someone point to ways in which it is
> > not safe, for my enlightenment? Is the nature of the unsafe-ness such that
> > I can handle it by using a mutex to prevent more than one thread at a time
> > from entering any of my code (two sections of code) that use libxml or is
> > it of a more serious nature?
> >
> > I've gone so far as to be nearly ready to deliver product that uses it in a
> > multithreaded way, so this revelation has my heart up in my throat.
> >
> > Details will be appreciated.
> >
> > Fred
> >
> >
> >
> >
> > Gary Pennington <Gary Pennington uk sun com> on 06/25/2001 04:47:52 AM
> >
> > To:   Steven James Pulito <spulito givingcapital com>
> > cc:   xml gnome org, xslt gnome org (bcc: Fred Smith/Computrition)
> > Subject:  Re: [xml] thread safe?
> >
> >
> >
> >
> > Neither is thread-safe.
> > Gary
> > Steven James Pulito wrote:
> > > What is the status of limxml and libxslt as far as thread safety??
> > >
> > > Thanks,
> > > Steve
> > >
> > > _______________________________________________
> > > xml mailing list
> > > xml gnome org
> > > http://mail.gnome.org/mailman/listinfo/xml
> > --
> > Gary Pennington
> > Solaris Kernel Development,
> > Sun Microsystems
> > Gary Pennington sun com
> >
> >
> >
> > _______________________________________________
> > xml mailing list
> > xml gnome org
> > http://mail.gnome.org/mailman/listinfo/xml
> >
> >
> >
> >
> >
> > _______________________________________________
> > xml mailing list
> > xml gnome org
> > http://mail.gnome.org/mailman/listinfo/xml
>
> _______________________________________________
> xml mailing list
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml

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