Re: [xml] libxml2 thread safety

[Daniel Veillard <veillard redhat com>]

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

  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

-- 
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/