Re: [xml] libxml2 thread safety

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
threadsafe framework.

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.

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


This brings up a very important point which I omitted to mention.

I hope that anyone who has developed a "thread-safe" (I use quotes because programming convention safety is not the same as real safety, but it is often enough for any given application) solution which is not based on pthreads will NOT be affected by this work. They should be able to compile the new libxml2 and find that their application behaves as it always has done. The combination of configure and the macros REENTRANT and POSIX_C_SOURCE etc.. identify code which is being compiled for a pthreads environment and will allow us to configure the library "correctly" for any given execution environment. If the thread-abstraction suggestion is taken up, the detection of appropriate platform support will still be a requirement and is one reason why a thread-abstraction API may not be a good way forward. I'm not planning on writing a cross-platform threads library.

Any solutions which have been implemented to use pthreads, will find that some of the work performed to ensure thread safety is now redundnant. Also, some care will need to be taken to make sure they interact well with the proposed changes. Actually, to anyone who has already done this work I say - where is it?

I think that adopting an abstraction layer with respect to the threads library is a distinct possibility, I'm keeping an open mind on that subject. With respect to certain APIs which manipulate buffers, it's distinctly possible that new APIs may be introduced in a re-entrant form to supplement existing APIs, similiar to strtok_r and strtok in libc. This decision awaits a more detailed analysis of the existing APIs.


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

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