RE: [boost] Singleton (with Singleton Registry: Clarification)

From: Mithun R K (mithun.radhakrishnan_at_[hidden])
Date: 2005-01-13 10:34:51

Hello, Scott/Jason/All.

Thank you for having looked at this approach.

Scott, I'm not entirely sure I've understood everything you've said... I
apologise if I've not made my approach clear. I'm afraid I might have messed
up in explaining it.

<quote>
While I can see where it is headed and can imagine that it will solve a set
of problems, does it solve the typical problem? [snip] This is different to
the CRT model... 
</quote>

What does one mean by the "typical problem"? And by "the CRT model", do we
refer to Jason's new code?

<quote>
The perfect ordering of global ctor+dtor is runtime dependent, i.e. the
sequence of ctor's and dtor's alters from one execution to another. 
</quote>

What I was aiming at was to destroy Singleton objects in a predetermined
order, based on the longevity-ints specified, *regardless* of the order of
construction. E.g. I'd like my Logger instance to be "alive" until all other
Singleton instances are destroyed (because destructors log). I'd like this
irrespective of when the first log-request was made (and the Logger was
constructed). So I set the Logger's longevity-int to max.

Here's how I postpone destruction. The Singleton constructor looks like:

/*private*/ Singleton<T>::Singleton()
                : SingletonBase( Longevity ), T()
{
        static SingletonUnregisterer unregisterer(this) ; // <-------------
1
        SingletonRegistry::getInstance().registerSingleton( this ) ; // <--
2
}

/*static*/ T& Singleton<T>::getInstance()
{
        static T* pInstance = new Singleton<T> ;
        return *pInstance ;
}

At Line#2, the SingletonRegistry gets a handle to the Singleton instance.
Line#1 here is a hack. SingletonUnregisterer is a class whose dtor
"unregisters" the Singleton from the SingletonRegistry. The dtor is
triggered when the library unloads, or the app exits.
Unregistration doesn't necessarily destroy the Singleton immediately. It
merely marks the Singleton as ready for destruction. The object won't be
destroyed (deleted) until all objects with lesser longevity are
marked/destroyed. Since the Logger's longevity is max, it will be destroyed
last (after all other Singletons have been destroyed, and all their
destructors have finished logging). Similarly, the rest. Please comment?

I read the article you pointed me to... With respect, shouldn't the above
take care of de-initialization order?

<quote>
If your model is different to the "real" model (ctor+dtor sequence is
runtime dependent), what will you achieve with it?
</quote>

With the above, I (hoped to) achieve a predetermined order of destruction of
static singletons, even if the ctor-sequence is runtime-dependent... 

<quote>
If someone wth a dtor dependency issue discovers your "longevity-int"
feature, applies it to a complex codebase only to discover that the true
problem is outside the domain of an "ordering ints" strategy,  is the wasted
effort entirely their fault? A ridiculous question posed to make a point.
</quote>

I'm really sorry, but I couldn't follow, again... I'm not sure whose fault
it is if someone mistakes the "true problem" to be a
singleton-deinitialization-problem, when it isn't... (Did I get that right?)

I look forward to further comments.

Many thanx,
Mithun

-----Original Message-----
From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of Scott Woods
Sent: Thursday, January 13, 2005 6:46 AM
To: boost_at_[hidden]
Subject: Re: [boost] Singleton

----- Original Message -----
From: "Jason Hise" <chaos_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, January 12, 2005 11:07 AM
Subject: Re: [boost] Singleton

[snip]

>My approach was:
>
>1. Have a single SingletonRegistry that would keep pointers to all
Singleton
>instances (well, actually, SingletonBase instances. SingletonBase is 
>not a
>class-template.)
>2. Each instance has a longevity-int associated with it. At 
>destruction-time, we sort the singleton-instances based on their 
>relative longevities, and destroy the objects in order.
>It's kinda up to the "client" of Singleton<T> to figure out the 
>collaboration between her classes, and assign longevity-values to her 
>classes.
>3. Singleton<T> instances are "registered" with the SingletonRegistry, 
>by its constructor.
>4. Singleton<T>::~Singleton() lets the registry know that the instance 
>may be destroyed. The SingletonRegistry destroys the instance if all 
>singletons with a lesser longevity have already been marked for 
>destruction. (I guess that's simple mark-and-sweep.)
>
>I'd be honoured and grateful if anyone has comments on this approach.

At your command :-)

Apologies for the delayed response but I was waiting for this to develop.
Instead
it seems to have gone elsewhere.

After struggling with the issue of ctor+dtor of C++ globals for some time, I
wonder at the efficacy of your own intentions, WRT correct dtor of
singletons.

While I can see where it is headed and can imagine that it will solve a set
of problems, does it solve the typical problem? Assigning some ordering
"longevity-int" is creating another "model of destruction". This is
different to the CRT model and more significantly, configurable.

The perfect ordering of global ctor+dtor is runtime dependent, i.e. the
sequence of ctor's and dtor's alters from one execution to another.

Here's one instance of related research by others;

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.13

If your model is different to the "real" model (ctor+dtor sequence is
runtime dependent), what will you achieve with it?

If someone wth a dtor dependency issue discovers your "longevity-int"
feature, applies it to a complex codebase only to discover that the true
problem is outside the domain of an "ordering ints" strategy,  is the wasted
effort entirely their fault? A ridiculous question posed to make a point.

Only hoping to reduce your workload. Developing the singleton template is
starting to look like a real job.

Cheers,
Scott

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost