Re: [xml] libxml2 thread safety (SUMMARY)

[Daniel Veillard <veillard redhat com>]

On Thu, Oct 04, 2001 at 11:43:26AM +0100, Gary Pennington wrote:
> >  Okay, I would not call this beautiful but it is acceptable if contained
> > to a limited area. There is also 2 places where I would need to take a lock
> > in other places in the code. I suggest the following:
> >    - sepearate the global state definition in a state.h header
> >    - move all this code and definitions of the global variables in
> >      a state.c module
> >    - export the locking as a libxml function and data to help portability,
> >      this is not a full encapsulation of a thread system, just the
> >      create/lock/unlock/destroy of a lock since it will be used in other
> >      places in libxml (and possibly libxslt too).
> I would propose adding two functions to support locking/unlocking of the 
> parser context. I don't think that I will export the lock create/destroy 
> since that is internal to the library and should have nothing to do with 
> any consumers. I'll think more about the utility of internal 
> functions/macros to do this.

  I would need to add locking to XPath and Catalog implementation.
This mean I need to create and destroy locks. I want an uniform way to
do this within the library.

> >  I would go for the latter. For example the predefined entities list 
> > is global and should be shared by all threads, I would not put it in
> > the structure. Other variables are harder, like the Catalog ones, it
> > could make sense to maintain them per thread but they are costly to build,
> > this is not simple to decide.
> I will need some help here. I have a candidate list (which is all the 
> exported clearly non-static variables in 2.4.5) could you go through 
> this list and indicate to me which globals should be thread specific.
>
> Here's the list (ignore the undef):
>
> #undef  docbDefaultSAXHandler

  shared The default sax values are overridable independantly so it's
better to keep them shared IMHO

> #undef  htmlDefaultSAXHandler

  shared 

> #undef  oldXMLWDcompatibility

  local

> #undef  xmlBufferAllocScheme

  local

> #undef  xmlDefaultBufferSize

  local

> #undef  xmlDefaultSAXHandler

  shared 

> #undef  xmlDefaultSAXLocator

  shared 

> #undef  xmlDoValidityCheckingDefaultValue

  local

> #undef  xmlGetWarningsDefaultValue

  local

> #undef  xmlIndentTreeOutput

  local

> #undef  xmlKeepBlanksDefaultValue

  local

> #undef  xmlLineNumbersDefaultValue

  local

> #undef  xmlLoadExtDtdDefaultValue

  local

> #undef  xmlParserDebugEntities

  local

> #undef  xmlParserVersion

  shared 

> #undef  xmlPedanticParserDefaultValue

  local

> #undef  xmlSubstituteEntitiesDefaultValue

  local

> #undef  xmlSaveNoEmptyTags

  local


> #undef  xmlStringComment

  shared 

> #undef  xmlStringText

  shared 

> #undef  xmlStringTextNoenc

  shared 

> #undef  xmlGenericError
> #undef  xmlGenericErrorContext

  local but I can see that sometimes people would prefer to change
it once for all threads

> #undef  xmlFree
> #undef  xmlMalloc
> #undef  xmlMemStrdup
> #undef  xmlRealloc

  Hum ... per-thread allocation mechanism is powerful but really
dangerous. Note that they should be kept initialized.
People have argued in the past taht it would be great to have memory
pools to make deallocation O(1) like in Apache

> I know that some of them are clearly not meant to be re-defined on a 
> per-thread basis, e.g. xmlMalloc but I've left them in for completeness 
> sake. Could you indicate which variables should go in the structure in 
> your opinion? I will assume that any variables which aren't intended to 
> be changed by consumers are the ones left over and they will be clearly 
> documented as such when this work is done.
>
> A consequence of this work is that no more global state should be 
> introduced into libxml2, at least not unless it's completely 
> unavoidable. We want to minimise the amount of global state to make 
> movement to libxml3 as painless as possible.

  Seems you missed the Catalogs module at least. And having global state
there clearly makes sense.

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/