RE: [xml] win32 threads feedback

["Stéphane Bidoul" <stephane bidoul softwareag com>]

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

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.

-sbi