Le 05/08/2016 à 19:25, Richard Heck a écrit :
I've suggested it before, but: Why can't we just test for this in configure?
The reason is that testing for its availability is not sufficient. Indeed, one also has to have a ready replacement that does something similar enough. Otherwise, every time, one has to implement two different logics. There are several reasons why this would be bad, one of which being that debugging threading issues is already complicated enough by itself.
Granted, it is a hassle, but we keep running into problems very much like this one. See also the issues with mingw.
On the contrary, let's find for each problem its appropriate solution. I think that the appropriate solution for thread_local is not to use it for now. As for mingw, it appears that it can be solved by using an appropriate compiler and linker switch. If a third kind of problem appears that is solved with a configure switch then one would rely on configure. I would be happy to hear from Georg about these issues too, but I guess that he must still be very busy currently. There was a consensus to switch programming languages, from c++98/03 to c++11. This is a big change, and some experimenting is necessary to know which extent of it is well-supported cross-platform. When everything will be figured out, the code will find itself with fewer configure switches, fewer platform-dependent headers and implementations, fewer supporting libraries, and more examples of concise code that can be written with the new idioms. In the case of multi-threading, the multitude of "FIXME THREAD" comments lets me think that LyX could use some of the new threading facilities that give simple solutions to old problems, and this is why somebody has to experiment with them for other developers to feel confident about them. Guillaume
