Jean-Marc Lasgouttes wrote: > 08/10/2013 14:24, Jean-Marc Lasgouttes: >> 07/10/2013 23:24, Georg Baum: >> >> Is there something like per-thread static storage? We do not really need >> mutexes, since it is not concurrent access to the same information.
thread-local storage does unfortunately still not work on non-POD types with gcc (my bug which I filed in 2006 is still open), but pointers work fine. > For example, is the following useful? > http://www.boost.org/doc/libs/1_35_0/doc/html/thread/thread_local_storage.html This should be useful, but like Vincent I think that QThreadStorage would be more suitable in LyX, since it interacts closely with QThread. However, I investigated the problem a bit more, and found out that there are more problems than the static buffer in iconv_convert(). My main question is this: Is the iconv() function really not thread safe, as the fix for bug 7240 suggests? Searching on the web seems to suggest that iconv may be used simultanously by multiple threads as long as each uses its own conversion descriptor (unfortunately I could not find anything in POSIX, only in some implementations like http://modman.unixdev.net/?sektion=3&page=iconv&manpath=HP-UX-11.11 and http://publib.boulder.ibm.com/infocenter/zvm/v6r1/topic/com.ibm.zvm.v610.edclv/iconvp.htm). This makes much sense to me, but if this is true the lock in IconvProcessor::convert() is wrong. Instead, one would need to lock each static IconvProcessor instance before using it (and of course the static maps of IconvProcessors). If the problem is really iconv() then IconvProcessor::Impl::mutex_ needs to be made static, and of course the other static variables in unicode.cpp need to be made thread-local or protected with a lock. Georg
