Re: [xml] libxml2 thread safety
- From: Daniel Veillard <veillard redhat com>
- To: robert <robert xml 00008 org>
- Cc: Gary Pennington <Gary Pennington uk sun com>, xml gnome org
- Subject: Re: [xml] libxml2 thread safety
- Date: Tue, 2 Oct 2001 12:12:50 -0400
On Tue, Oct 02, 2001 at 05:36:34PM +0200, robert wrote:
>1. To make libxml2 thread safe whilst preserving backwards compatibility
>as much as possible.
>2. One library, which implements all required threaded and non-threaded
>3. A guide to migrating existing code (Hopefully, this will be
>"recompile existing multi-threaded apps else do nothing").
>0. Use the same widely implemented threads package on all supported
>platforms to minimize porting work. Currently only pthreads is under
FYI, I'm using libxml2 and libxslt in a multi-threaded environment, which
is not one of the 'widely implemented threads packages' around.
Getting the code to work requires some nasty stuff (mostly on the part of
my application, though), but because of the readily available callbacks
for both memory- and I/O-handling, libxml2 does provide a good part of a
Ofcourse, global variables are a potential problem, but because of the way
I use the library those variables need no mutex-protection in my case.
There is actually 2 kinds of global variables:
- real ones like the XML predefined entities table, which are truely
global and should stay read only
- preference global variables which are currently used to avoid entry
points like xmlParseFile to have 20 arguments.
Differenciating the handling of both is a good idea. The first one shall
be initializable using xmlInitParser (). The second one should be encapsulated
in a preference type which could be passed to the entry points to set the
defaults for the work (within a given thread).
If this analysis covers all cases of global variable uses, then implementing
that scheme might be sufficient to provide guidance on how to write
multi-threaded apps without needing to actually add any thread specific code
in the library itself.
My suggestion: if possible, don't tie the package to some threads package
or another, perhaps using another abstraction layer which uses callbacks or
macros to perform tasks like locking data or thread-safe I/O (preferably
with an application-supplied context, which the current I/O callbacks are
lacking, hence the 'nasty stuff' ;).
I tend to agree with this.
Another couple of points I would like to raise are:
- making the library fully thread safe seems impossible, all the
tree access routines would be a mess to make thread safe. The goal
should be to make sure that separate threads can parse and manipulate
separate documents without troubles
- we should try to see how existing code accessing global variables
could be preserved, currently my best bet is to use an overridable
function returning the thread current "preference set" and
using macros to preserve the compatibility:
#define xmlSubstituteEntitiesDefaultValue xmlGetPref().SubstituteEntities
Interesting topic, I would be very happy to see this cleaned up,
Daniel Veillard | Red Hat Network http://redhat.com/products/network/
veillard redhat com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev