[boost] Re: Re: Singleton

From: Philippe Mori (philippe_mori_at_[hidden])
Date: 2005-01-10 22:42:02

> Philippe Mori wrote:
> 
>> ...what is needed to cover such cases is the ability to set the object 
>> in a "destroying" state.
>> A solution that could work in some situation would be something 
>> similar to:
>>
>> Singleton::Deconnect()
>> {
>>    if (object)
>>    {
>>        object->Deconnect();
>>    }
>> }
>>
>> Well, the way to do the deconnection on the object hold by the 
>> singleton would not be an hard-coded member but something that would 
>> be settable by a policy class or some other template mean (for
>> example, type trait).
> 
> I may be confused, but why couldn't (or shouldn't) this code be taken 
> care of by the singleton's destructor in the derived class?  It would 
> seem that the derived singleton is the only thing that could possibly 
> know about the specific things it needs to deallocate, and that a 
> destructor would be a natural place to take care of it.
> 
> -Jason
> 

In some situations, we want to "shutdown" an application while
there are still references to the singleton (for exemple static variables)
and we want objects to be destroyed sooner that what will happen by 
default.

If it is difficult to guarantee that a singleton will not be used till 
after a given point (where we want explicit destruction), it might
be safer to simply "Deconnect" the object. That is, delete is not 
yet called but we do some cleanup (particulary removing references 
to other object (or singleton)).

At my previous job we were using a lot of singleton where some 
where in DLL and others would uses COM (ActiveX) object and
since some objects were having reference to others, if we were
not forcing a shutdown by calling a function on appropriate 
singleton object, not every object was destroyed before we
call CoFreeUnusedLibrairies or before main was exited and DLL 
where unloaded by the system.

And since with dynamically loaded DLL, the system does not 
knows depedencies, singletons where destroyed in the order 
that Windows decides to unload the DLL. The problem would 
then occurs when while destroying a static object (typically a 
singleton) that was referencing something in a DLL that the 
system has unloaded, a crash would occurs.

Philippe