Hello, As you said on windows this a problem, because these ImageIO libraries are still static in a shared build. So there may be multiple of the HasBeenRegistered for each dll. While for some application it's easy to control where the registration occurs for larger its much more complex.
Perhaps specifically consider SimpleITK build with ITK with both shared libraries. In SimpleITK only the registration occurs just in the IO sub-library. However, if the applications wants to use both ITK and SimpleITK, its very likely that the registration will happen again. If I understand what in means to link the static libraries to a dll, this may reck havoc on third party libraries singleton-type data as there may be multiple versions in each dll. Slicer is one example of the above situation with ITK and SimpleITK. Additionally, it has extensions where a single file gets compiled into both a dynamic library and an executable. The current define ITK_NO_IO_FACTORY_REGISTER_MANAGER before "using ITK", does not provide the needed flexibility for such situations. Does it sound easier to address these issues for each application or could the ImageIO be made shared on windows? The reason I am thinking about this issue so much is the quarter million of valgrind errors I got from mixing static ITK libraries with shared simpleITK libraries[1] mostly appear related to HDF5 and GDCM static initialization and destruction. And have been pondering what this means for Windows libraries. http://open.cdash.org/viewDynamicAnalysisFile.php?id=2736128 Brad On Apr 12, 2012, at 1:51 PM, Brad King wrote: > On Thu, Apr 12, 2012 at 1:23 PM, Bradley Lowekamp > <[email protected]> wrote: >> static bool MetaImageIOFactoryHasBeenRegistered; >> >> I don't under stand how MetaImageIOFactoryHasBeenRegistered gets initialized >> before usage. And then is the static initialization fiasco [1] an issue? > > When the type of a global is a plain-old-data (POD) type the compiler > default-initializes it to zero (false for bool). We purposely take > advantage of default initialization because the code that > modifies/tests the variable may be invoked during static initalization > of *another* translation unit. If we had an explicit initializer then > it would overwrite whatever work had been done so far (from other > translation units) when the translation unit defining the global is > explicitly initialized. > > This approach is the same as some vendors' standard libraries use to > initialize singletons like "cout" and "cerr" AFAIK. > > -Brad K ======================================================== Bradley Lowekamp Medical Science and Computing for Office of High Performance Computing and Communications National Library of Medicine [email protected]
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-developers
