Just an update on my end. After digging into the source I found that the variables such as "xmlLoadExtDtdDefaultValue" are not variables but dereferenced memory from function calls that return the memory location based on the threads context and if there is thread support. So to summarize, this code will still work when thread support is enabled without any changes.
It would be helpful to mention in the threads.html that global values and functions will be defined in a manner that does not require any source changes in user's multithreaded code. I know by the virtue of not saying these changes were required it should have been clear enough, however the API documentation show these as global variables and from a semantic point of view global variables would never be thread independant. That is why I had to take the time to understand that these truely were not global variables. Thanks, James On Fri, Jun 12, 2009 at 1:24 PM, James Hart <[email protected]> wrote: > I am working in an application where there are separate components, in > different threads, that don't know about each other but may need different > global parmaters set. I found the blurb about thread safety > http://xmlsoft.org/threads.html, but the documentation about globals > themselves in a thread situation seems to be lacking or it is so simple I'm > missing the how. > > Currently a component may do this: > 1. xmlLoadExtDtdDefaultValue = XML_DETECT_IDS | XML_COMPLETE_ATTRS; > 2. xmlSubstituteEntitiesDefault(1); > > With thread support turned on will line 1 and 2 in thread A. not affect the > behavior in thread B? If not, what is the proper way to change the behavior > in thread A based on these global value and functions so they do not affect > thread B? > > > Thanks, > James > > -- If there is anything bigger than my ego around, I want it caught and shot now!
_______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
