Re: [xml] libxml2 thread safety
- From: Gary Pennington <Gary Pennington uk sun com>
- To: robert <robert xml 00008 org>
- Cc: xml gnome org
- Subject: Re: [xml] libxml2 thread safety
- Date: Tue, 02 Oct 2001 16:59:07 +0100
>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.
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.
Solaris Kernel Development,
Gary Pennington sun com
] [Thread Prev