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
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.

I can give it a try if you want. What would be the #define to
test for to know we are compiling as a DLL or static lib?

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 :-)

Yeah, I'm still having difficulties to get a firm
grasp of libxml's behaviour wrt threading...
That's why I may sound fuzzy...

When enabling threads in libxml, I think only 2 things are done:
- the globals are instanciated per thread
- the mutex API becomes functional
  [and that mutex API in used only in catalog.c
  -- that's what I meant]

Can you confirm that for me?

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.

Ok. But most (all?) of those values can also
be specified on the parser context, no?

Thanks for helping.


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