Re: [xml] libxml2 thread safety

[Gary Pennington <Gary Pennington uk sun com>]

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
> >behaviours.
> >3. A guide to migrating existing code (Hopefully, this will be
> >"recompile existing multi-threaded apps else do nothing").
> >
> >
> >Approach
> >
> >0. Use the same widely implemented threads package on all supported
> >platforms to minimize porting work. Currently only pthreads is under
> >consideration.
>
> 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' ;).
>
>                                                                     robert
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

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