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

From: Scott Woods (scottw_at_[hidden])
Date: 2005-01-13 16:12:24

----- Original Message -----
From: "Mithun R K" <mithun.radhakrishnan_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, January 14, 2005 4:34 AM
Subject: RE: [boost] Singleton (with Singleton Registry: Clarification)

> 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.

No, you explained it fine. Its the direction and associated ramifications
that I was making observations on. Poorly :-)

>
> <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?

The "typical problem" is that objects in any substantial application want
to be destroyed in a runtime-dependent order. The exact order is driven
by what activity occurs during execution. Trying to dictate an order (i.e.
longevity-int) onto something that is dynamic is... misdirected.

What I am describing here can equally be applied to the default order
of dtor imposed by the C runtime (CRT order).

Whether the imposed, *fixed* order is CRT or longevity-int it will
eventually
be the wrong order for some execution path of your application.

longevity-int prioritizing may reduce the ordering problem, I cant really
say. But it would certainly be a significant thing to implement and
maintain.
With all that effort, there could be disappointment when an application
still crashes on termination.

ps:
By CRT I mean the order of dtor of global objects imposed by
the C runtime.

>
> <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.

Its the pre-determined order that is the problem.

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

Again; you do not know the required order of destruction at compile-time.

> <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.

No worries Mithun. If I havent successfully made my point now then
its probably best to just carry on. My observations come from several
attempts to impose strategies onto dtor-ordering (and also ctor-ordering).
These experiences have been fairly humbling. My favorite technique these
days involves something that is known as "function guards" (as per the
link provided previously) and "custom dependency work" (hacking).

important_object &
object1()
{
    static important_object *p = new important_object;
    return *p;
}

// Hack example; forces instantiation during CSV

static important_object &r = object1();

Cheers,
Scott