------- Comment #27 from mrsam at courier-mta dot com 2009-06-16 21:54 ------- I thought of that, but using a vector will not be thread safe. Although I don't believe that the C++ standard requires thread safety for std::messages, applications will definitely expect thread safety here. The underlying libintl functions are thread safe.
libstdc++ does include some thread and mutex support, but it's not in the current C++ standard, AFAIK, and I'm not sure if mutexes can be used in the localization library. Using a vector does give rise to a couple of other issues, though: * Applications may rely on the libstdc++ existing implementation of ignoring the return value of open(). I don't know if breaking those applications would be permitted. * It's going to be extra-messy. Even though the only change to the class is the addition of a static class member, which should have only minimal ABI considerations, the existing do_open() code is declared in application-exportable headers (but not do_get()). I think that means that existing applications may have the existing do_open() code compiled into them, so this requires the approach in my last patch, of bundling it into the subclass. If someone can confirm that there won't be any issues with using static mutex objects in code that supports std::messages, I can try to write this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
