Tobias Schwinger wrote:
JOAQUIN LOPEZ MU?Z wrote:
----- Mensaje original ----- De: Tobias Schwinger <tschwinger@isonews2.com> Fecha: Sábado, Agosto 25, 2007 1:06 am Asunto: Re: [boost] Threadsafe singleton - questions Para: boost@lists.boost.org
Robert Ramey wrote: [...]
g) what happens if same interface used by different DLLS. Is one instance still created? Yes. Are you sure? For instance, in Windows globals aren't merged on DLL loading, so if you've got something like:
Currently, not even symbol merging can keep us from potential breakage. It can even make things worse, at cases (see below). <code>
you'll get different t1 and t2 values.
Right.
...which (after some more thinking about how Singletons should work with across dynamic library boundaries) is in fact a good thing since a dynamic library shouldn't make any assumptions about when it gets unloaded.
I don't see how you're able to prevent this behavior for the local static data of singleton_manager.
The data is initialized (and inserted into the manager's list) by the Singleton itself, while the manager just handles destruction. Still problematic, however.
Not at all: As client Singletons are user classes it's the users responsibility to eventually add declspec stuff for windows.
It should probably be mentioned in the docs. Thanks for the heads up.
Unfortunately, it's not that simple... A Singleton that is exposed in the header will currently get inlined into the client (including the manager) which can cause serious trouble: A Singleton might end up to exist multiple times and a destructor located in already-unloaded code. This situation can even occur if a dynamic library uses a Singleton internally and symbols get merged (unless merging is #pragmaTically disabled, which might not be possible for all ABIs). The good news: The next version will introduce means for full control over what happens in all sorts of shared library scenarios. Thanks again. Regards, Tobias