This is one of the more important threadsafety issues because of export in
thread and simultanous view source. The solution is ugly, but a better one
(see FIXME) would require major rework. These static variables should not
have been used in the first place IMHO.
Using a static variable here was premature optimization: fileNames() is only
called from GuiRef (directly or indirectly), and since this is a dialog the
copying of a FileNameList is not noticeable at all.
In this case I use a mutex, so the zip status of files is shared between
threads. This is possible because a deadlock can't happen, and it should give
better performance.
Don't create an intermediate copy (found by Jean-Marc).
I doubt that this has anything to do with the mystery crash, but it works, and
following the standard patterns is better anyway.
Without this, you get crashes in a few second when you set the autosave
interval to one second and edit quickly (typing new words etc). The reason
is that the cloned buffer wants to insert words into the word list and
remove them again, but it lives in a different thread.
The lyx2lyx conversion for format 352 was incomplete: It should have been
added the \use_indices setting, but it relied on the fact that the default in
LyX for missing \use_indices is the same as the old format without that
setting used. However, the default might change in the future, and later
lyx2lyx conversions rely on that setting as well.
The compiler-generated copy-constructor and assigment operators would be wrong
for IconvProcessor::Impl, since cd would be copied, and iconv_close() could
thus be called twice on the same descriptor. The old code did work, but now
IconvProcessor::Impl cannot be copied by accident in the future.
The IconvProcessor assignment operator did not delete pimpl_ and used a
non-standard signature. If you want to know why the standard signature is
important, read "Effective C++" by Scott Meyers.
The statement
if (pos < from + lyxrc.completion_minlength)
triggers a signed vs. unsigned warning. I don't know why this happens, it
could be a MSVC bug, or related to LLP64 (windows) vs. LP64 (unix)
programming model, or the C++ standard might be ambigous in the section
defining the "usual arithmetic conversions". However, using a temporary
variable is safe and works on all compilers.
The configuration time suffers mostly on checking, which of the export tests
is to be reverted.
1.) There is a new configuration flag now, "LYX_ENABLE_EXOPRT_TESTS.
If not set (default) no export tests are created.
2.) If set, then the optimization halves the time needed for creation of tests.
The effect on my side:
a.) Until now the time was: ~ 26 seconds
b.) The optimized time is now: ~ 16 seconds
c.) With not enabled export tests: ~ 5 seconds
