On 11/20/2014 02:39 PM, Abdelrazak Younes wrote:
Hi Georg,
Warning: I haven't read LyX source code for a long long time :-)
On 19/11/2014 22:43, Georg Baum wrote:
Hi,
while investigating http://www.lyx.org/trac/ticket/9336 I found out a
fundamental problem with our multithreaded export: The GNU libstdc++
gives
only a relatively weak thread-safety guarantee about std::basic
string. It
is not completely thread-safe in the POSIX sense. The reason for this
lies
in the employed copy-on-write technique, which is not used in other STL
implementations such as the one in clang or MSVC. It is even explicitly
forbidden in the new C++11 standard, and the gcc folks already
acknowledged
that they will get rid of it, but since this is an ABI incompatible
change
they want to wait until they have several such changes to do all in
one go.
For details please see the excellent gcc bug report by James Kanze
(who is a
C++ expert) at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334,
especially https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334#c21, which
describes almost exactly the situation we have with the document
language.
This looks all rather theoretical, but in practice it means that it
is quite
easy to produce crashes if you use LyX built with #define
EXPORT_in_THREAD 1
and gcc, and start an export, depending on the document (master-child
setups
seem to be much more vulnerable). The thing which seems to be most
affected
is Language::babel_, which is copied a lot, but problems could arise
from
all std::string and docstring variables.
I am not questioning your reasoning but I think STL thread safety
limitation has limited impact in our case. AFAIR, the Buffer is cloned
in in the current and main thread so we have no race condition here.
After that the cloned buffer shares nothing with the original Buffer
and can thus be used safely in another thread.
Yes, that is correct as to how the cloning happens. I'm no expert as to
the rest.
Richard
