Re: [xml] libxml2 thread safety

[Daniel Veillard <veillard redhat com>]

On Tue, Oct 02, 2001 at 04:59:07PM +0100, Gary Pennington wrote:
> 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 

  Too complex.

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

  Been there, done that a couple of time, no joy, no 2 thread implementations
have strictly similar synchronization semantics, this is really hell to
maintain.
  I would even go as far as "we don't need to link directly to any
thread code".

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

  I think:
    - we need to provide a way to map global variables via an overwritable
      function indirection. xmlGetPref() will normally return always the
      same area. If you use threads and want distint preferences per thread
      simply do xmlGetPref = myGetPref , that code, user provided, will
      access thread info if needed.
    - we need to make sure the library initialization function covers
      all global read-only variables.
    - we need to double check a couple of things in XPath and Catalogs
      processing which may require synchronization and possibly provide
      another overwritable function for this
    - add in the configure.in the extra flags needed for thread safe
      compilation because X or Y is broken otherwise on the platforms
    - write a small tutorial on how to use the library in a thread safe
      manner (and the extend to which it will work ... 2 threads accessing
      the same xmlDocPtr shall synchronize outside of the library)

 In a nutshell I would rather avoid actually adding thread aware code in
the library but make sure it's possible to use it in this manner, delegate
the couple of entry points needed and provide appropriate doc.

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/