Re: [xml] side effects of thread-enabling libxml2

On Fri, May 09, 2003 at 06:06:04PM +0200, Stéphane Bidoul wrote:
I think I suggested adding functions
to register the global default values and the other things
needed would be
to take a lock when initializing a thread set of local variables.

Ah, it's that one... Bon, let's see if I got it, this time.
Something like this, generated from

/* the new variable */
static xmlGenericErrorFunc xmlGlobalGenericError =

/* SetGlobal */
void xmlSetGlobalGenericError(xmlGenericErrorFunc v)
  xmlGlobalGenericError = v;

/* GetGlobal */
xmlGenericErrorFunc xmlGetGlobalGenericError()
  xmlGenericErrorFunc ret;
  ret = xmlGlobalGenericError ;
  return ret;

  yup something like that. Be careful, may just be outdated ...

- xmlInitializeGlobalState adapted to initialize from
xmlGlobal values and to acquire/release the lock
- All SetGlobal/GetGlobal added in libxml2-api.xml

  Sounds right

I'm not sure what to do with the following calls in
xmlInitializeGlobalState: initGenericErrorDefaultFunc,
inithtmlDefaultSAXHandler, initdocbDefaultSAXHandler,

  I would keep them as-is I think, they will still read from the
global SAX data area. Not 100% sure though, this might require some

And the globals for the main thread will *not* be initialized
from the new xmlGlobal values, right?

  Why not ?


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]