On Thu, Jul 2, 2015 at 2:56 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Thu, Jul 2, 2015 at 5:54 PM, Matt Turner <matts...@gmail.com> wrote: >> On Thu, Jul 2, 2015 at 2:22 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>> Can this be done at dlopen/init time? For example what happens if you do >>> >>> static int foo = _mesa_locale_init() >>> >>> IIRC things like that are possible in C++, not sure about C. >> >> gcc has __attribute__((constructor)). >> >> But I don't think we really care... Erik's series converted the strtod >> code from C++ to C (including moving locale init from being a static >> constructor to being called in one_time_init) and fixing the memory >> leak. > > Well, this is just going to happen over and over again, I was hoping > there was an easy way to do static initializers in C. If not, then I > guess we're stuck with this.
The good news is that the breakage was noticed real quick. I agree that it'd be awesome to have this happen automatically, but AFAIK there's no perfect solution for this: * C++ static object initializer leads to libc++ dependencies. * __attribute__((constructor)) is compiler specific. * Naively mutex-protecting initialization leads to overhead in the common case. * Lighter-weight double checked locks are tricky to implement, and also have some overhead * pthread_once() is not available on Windows, and have some overhead Generally, it leaves a bad taste in the mouth to have to know about compiler-internals for being able to use the compiler. This could be slightly mitigated by introducing something like _mesa_glsl_init(), which means that call-sites only need to know about initializing the compiler. However, such a function would only call _mesa_locale_init() at this point, so we need to know the same amount of things. I'd introduce _mesa_glsl_init() only if it turns out we need to do more. Besides, new call-sites for _mesa_strto{d,f} will crash visible and hard if introduced without _mesa_locale_init. So, while not being awesome, I think this is the lesser evil for now. But maybe it would be more palatable to move this into initialize_context_to_defaults() instead, which is a shared initializer for stand-alone compilers? Perhaps it's more likely that this function gets called by other non-driver call-sites... It would also reduce the number of call-sites by one. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev