Re: [xml] win32 threads feedback

Stéphane Bidoul wrote:
That second thread is for freeing the global state when the first thread
terminates, right? I think one could achieve the same result by
using a DllMain and allocating the global state on DLL_THREAD_ATTACH,
and freeing on DLL_THREAD_DETACH. But that would
not work if libxml2 is linked statically, of course...
Would it make sense to implement that?

Well, back then I didn't do it because it would give even more #ifdefs in an allready overifdeffed threads.c. It would also generate mails of the sort "I think I found a bug: when I link dynamically everything is fine, but when I link statically, libxml produces extra threads"

Today, when I look at it, why not? The static and the dynamic libs are compiled independently anyway.

Well, I will need a thread safe libxml2, for the single mutex protecting
the global catalog (?).

Eh? May the Lord strike me down if I understood what you mean :-)

What I'm not sure, is why I need to have the globals instantiated per
thread, since they seem to be used as default values only?

Well, they contain default values, but are not constants. The thought was to enable two threads to parse two different documents at the same time, and that using different values in those variables.


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