Le 30/11/2014 20:31, Georg Baum a écrit :
Anyway, I id some experiments with different solutions:
forcecopy.diff shows how a solution with a small helper function looks like.
This is quite simply, but it requires to manually use it in all places where
strings could be copied in multiple threads. Not nice, but I think it is
doable.
Not nice indeed...
stringclass.diff shows an incomplete solution with an own string class. I
used docstring (this would be needed for std::string as well), since a
replacement of std::string would produce a huge diff. The advantage is that
you do not need to think about using a deep copy or not, but the
disadvantage is that you need to duplicate a lot of base class
functionality, and it produces warnings about ambigous operator+ (but
without these ambiguities, other parts of the code don't compile).
Another possibility could be to define a trivial_string class only for
storage in our objects. This class would not be able to do anything
besides reading and setting, but would be transparently compatible with
std::string. It seems to be that we could be able to just change the .h
files and be done with it.
I did not try Jean-Marcs suggestion about de-parallelizing the export and
only calling the external tools in parallel. I am pretty sure that it works,
however if we go this way then we basically say that we don't want parallel
code in LyX itself. Despite I like the idea very much I am not so sure
whether we should go this way, since the processor trend goes towards more
cores and more energy efficiency (which often means lower clock frequency),
so we might need to use parallelism even more in the future.
Agreed.
JMarc
