RE: [xml] side effects of thread-enabling libxml2
- From: "Stéphane Bidoul" <stephane bidoul softwareag com>
- To: <veillard redhat com>
- Cc: "'Gary Pennington'" <gary pennington sun com>, <xml gnome org>
- Subject: RE: [xml] side effects of thread-enabling libxml2
- Date: Fri, 9 May 2003 18:06:04 +0200
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]