Ion Gaztañaga escribió:
The lazy init does not work because somehow get() is being called in a static object (static_initializer()->init()), so it's lazily but *too early* instantiated.
This is aspect of Boost.Flyweight is by design, instantiation of the singleton class is made during the program dynamic initialization phase so as to avoid concurrency problems to a large extent (see http://tinyurl.com/38jknra ).
If intermodule_singleton is used as a singleton outside static classes in dlls, then I guess there is no problem.
No solution for my problem :-(
In the future I'll change intermodule_singleton to use windows_managed_shared_memory so that we can avoid any call to COM objects.
That'd be terrific. Do you have a roadmap for this?
According to microsoft documentation, we shouldn't even call C runtime memory management functions in DllMain, which is really frightening.
I've always found this particular restriction a little hard to justify (and really never saw a crash attributable to this): in the doc you refere to it reads: "The library loader. DLLs often have complex interdependencies that implicitly define the order in which they must be loaded. The library loader efficiently analyzes these dependencies, calculates the correct load order, and loads the DLLs in that order." and also "You should never perform the following tasks from within DllMain: [...] Use the memory management function from the dynamic C Run-Time (CRT). If the CRT DLL is not initialized, calls to these functions can cause the process to crash." Supposedly the library loader analysis should lead in every case to CRT DLL (which does not depend on any user-created DLL) being loaded *before* any user-created DLL, shouldn't it? Why then the caveat? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo