On Tue, May 6, 2014 at 6:04 AM, Kenneth Graunke <kenn...@whitecape.org> wrote: > On 05/05/2014 10:01 AM, Ian Romanick wrote: >> On 05/04/2014 02:14 PM, Chia-I Wu wrote: >>> On Sat, May 3, 2014 at 1:52 AM, Ian Romanick <i...@freedesktop.org> wrote: >>>> On 04/22/2014 01:58 AM, Chia-I Wu wrote: >>>>> There may be two contexts compiling shaders at the same time. locale_t >>>>> needs >>>>> to be protected. >>>> >>>> Rather than calling glsl_initialize_strtod from other places in the >>>> compiler, it seems better to use call_once from the strtof and strtod >>>> functions. >>> How about having a static object to call newlocale()/freelocale() in >>> its constructor/destructor? It will impose no overead on >>> glsl_strtod(), at the expense of little wasted memory when the >>> applications do not compile shaders. >> >> The problem I see with that is we don't know what order constructors on >> global objects will occur. Are we sure the contructor will be invoked >> before we need the locale now and in the future? > > These functions are used during lexing to read floating point > literals...without breaking on locales where the decimal point is a comma. > > All constructors have definitely been run by that point, and I can't > imagine we'll ever need to call locale-independent strtof/strtod from > other constructors. They are also used by the IR reader. But the IR reader is no longer used to parse built-in functions or so. We should be good as you said.
Not that we need this, and I am not saying this with 100% confidence, from my research on stackoverflow (instead of the standard, sorry), it is the initialization order of static objects from different translation units that are undefined. If this locale_t_initializer was defined statically in strtod.cpp, other static constructors calling glsl_strtod() would actually work because, by the time glsl_strtod() is called, locale_t_initializer is guaranteed to be initialized. Anyway, I should add some assert() just in case. > > --Ken > -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
