Re: [xml] libxml2 thread safety

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
  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 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 Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

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