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



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 global.data?

/* the new variable */
static xmlGenericErrorFunc xmlGlobalGenericError =
xmlGenericErrorDefaultFunc;

/* SetGlobal */
void xmlSetGlobalGenericError(xmlGenericErrorFunc v)
{
  ACQUIRE_LOCK
  xmlGlobalGenericError = v;
  RELEASE_LOCK
}

/* GetGlobal */
xmlGenericErrorFunc xmlGetGlobalGenericError()
{
  xmlGenericErrorFunc ret;
  ACQUIRE_LOCK
  ret = xmlGlobalGenericError ;
  RELEASE_LOCK
  return ret;
}

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

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

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

-sbi




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