wxXmlDocument and multithreading
Ferran
Is wxXmlDocument thread-safe?
I use wxXmlDocument in a multithreaded application. Different threads
have different instances of wxXmlDocument but it seems that Save
method is not thread-safe. My application sometimes crashes when two
threads are calling Save method of different wxXmlDocument instances.
I have seen that Save method uses a string conversion that uses
wxFontMapperBase that modifies gs_encodings global var. Perhaps, this
is the problem.
My code is:
...
wxString strRet;
wxStringOutputStream stream(&strRet);
if (pDoc->Save(stream,wxXML_NO_INDENTATION) == false)
{ LOG_ERROR(wxT("Error saving document into output
stream.")); return wxEmptyString;
}
...
Is there any known issue regarding this? I'm working with 2.8.0
version of wxWidgets.
I think that a workaround may be to use an static wxMutex o
wxCriticalSection to avoid the threads call Save method
simultaneously. What do you think?
Thanks for the help.
Best regards,
Ferran
Andreas Mohr
On Mon, Nov 02, 2009 at 09:00:44AM -0800, Ferran wrote:
>
> Hi all,
>
> Is wxXmlDocument thread-safe?
>
> I use wxXmlDocument in a multithreaded application. Different threads
> have different instances of wxXmlDocument but it seems that Save
> method is not thread-safe. My application sometimes crashes when two
> threads are calling Save method of different wxXmlDocument instances.
> I have seen that Save method uses a string conversion that uses
> wxFontMapperBase that modifies gs_encodings global var. Perhaps, this
> is the problem.
Perhaps, perhaps not. At least it's certainly a problem that they
reference a gs_encodings here (unless this global var is properly
locked).
To try to find out more, using helgrind might help (it is quite good
at finding things).
Good luck,
Andreas Mohr
Vadim Zeitlin
F> Is wxXmlDocument thread-safe?
As most of wx classes I don't think it was designed to be MT-safe so while
it's possible that it's "accidentally" MT-safe, I wouldn't be surprised if
it were not. And as it uses Expat library underneath, it would need to be
MT-safe itself too and I'm not sure about it neither.
F> I use wxXmlDocument in a multithreaded application. Different threads
F> have different instances of wxXmlDocument but it seems that Save
F> method is not thread-safe. My application sometimes crashes when two
F> threads are calling Save method of different wxXmlDocument instances.
Where do they crash?
F> I have seen that Save method uses a string conversion that uses
F> wxFontMapperBase that modifies gs_encodings global var. Perhaps, this
F> is the problem.
I seriously doubt it. gs_encodings is const and is not modified at all
unless I'm really missing something.
F> Is there any known issue regarding this? I'm working with 2.8.0
F> version of wxWidgets.
You really should be using 2.8.10. There were tons of bug fixes since
2.8.0 (which is almost 3 year old after all).
F> I think that a workaround may be to use an static wxMutex o
F> wxCriticalSection to avoid the threads call Save method
F> simultaneously. What do you think?
Serializing calls to wxXmlDocument::Save() like this should definitely
help if your problem is really MT-related (and not just some bug
elsewhere).
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Ferran
Thanks for your answers.
I will use helgrind, I didn't know it and it seem a very useful tool.
I have serialized calls to wxXmlDocument::Save and my application has
not crashed any more.
Vadim, you are right, I should use 2.8.10. I will upgrade as soon as I
can.
Will I have to do changes in my code in order to upgrade? In other
words, is version 2.8.10 fully compatible with 2.8.0 working code?
Regards,
Ferran
On Nov 3, 2:37 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> < 1KViewDownload
Vadim Zeitlin
F> Will I have to do changes in my code in order to upgrade? In other
F> words, is version 2.8.10 fully compatible with 2.8.0 working code?
Yes, it is, this is why 2.8 is a _stable_ release.
Kenneth Porter
wrote:
> Will I have to do changes in my code in order to upgrade? In other
> words, is version 2.8.10 fully compatible with 2.8.0 working code?
One should always test updated libraries before deployment, as there are
inevitably differences that can break an app.
I found that some of the sizing code in wxScrolledWindow changed in a way
that required tighter control over my frame's initial sizing computation to
get it to size correctly. (The old code sized the containing window to fit
everything it contained, which is what I wanted. The new code shrinks the
window down if it's large, forcing scroll bars to appear.)