Re: [xml] xmlNewTextWriterFilename Win32 Problem

[Coleman Brumley <coleman brumley comcast net>]

Bjorn,

Yes, of course you're correct and that's a flaw in my thread design.  
Thank you for pointing that out.  I had even tried an attempt at putting 
fname on the heap and that made things worse. 

So, likely what I'll do is:
populate fname
_beginthreadex(...,fname,...)
waitforsingleobject(...) --> the object will be set in the XMLReadData 
thread after the contents of fname are copied locally via memmove

However, that's a flaw in XMLReadData which doesn't have a problem.  
What threw me is that XMLWriteData is *not* multi threaded and only 
started exhibiting this behavior when I made XMLReadData a thread. If 
both functions remain single threaded, there is no problem.  That 
doesn't seem to me to be a synchronization issue and I don't see how 
improving the design of XMLReadData would have any effect. 

I will double check my project settings and see if I'm linked to the 
wrong multi-thread library or something. 

- Coleman

Bjorn Reese wrote:

> Coleman Brumley wrote:
>
> > I have a strange problem with xmlNewTextWriterFilename on Win32.
>
>
> I believe that your problem is related to multi-threading, not libxml
> per se.
>
> > I have two file name strings:
> > char outname[MAX_PATH]={(char)0};
> > static char fname[MAX_PATH]={(char)0};
>
>
> Are they global or local variables? The static keyword has two different
> meanings for these two cases.
>
> > outname gets passed to a function XMLWriteData(const char *file) 
> > which in turn calls xmlNewTextWriterFilename(file,0);.  As long as 
> > the fname variable (which gets passed to XMLReadData via the 
> > CreateThread function) is static, xmlNewTextWriterFilename crashes 
> > and generates an access violoation in NTDLL.
> > As soon as I change the declarations to:
> > char outname[MAX_PATH]={(char)0};
> > /*static*/ char fname[MAX_PATH]={(char)0};
> >
> > xmlNewTextWriteFilename works fine.
>
>
> I am going to assume that fname is a local variable. You can think of
> a static local variable as a global variable that cannot be seen from
> outside the function where it is defined.
>
> The point is that only one buffer exist in memory for fname. If you
> change the contents of fname, it will affect all threads. This can lead
> to strange behavior. So given the above information, my guess is that
> the observed behavior occurs because you access a shared resource
> (fname) from multiple threads without any synchronization.