Re: [xml] win32 threads feedback

[Igor Zlatkovic <igor zlatkovic com>]

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

Feel free.
#ifdef LIBXML_STATIC
-> static lib is being compiled
#else
-> dynamic lib is being compiled
#endif

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

Ahaaa, now I get it. Yes, that's what happens.

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

Not all. Only those that have 'DefaultValue' in their names are copied into 
the parser context when the context is created. Others are read directly 
where needed.

Ciao,
Igor