Re: [boost] [review] Fast track review of Boost.Utility/Singleton begins today

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-16 03:15:55

Pierre-Jules,

thank you for your review.

Pierre-Jules Tremblay wrote:
> On Jan 14, 2008 12:10 PM, John Torjo <john.groups_at_[hidden]> wrote:
> 
>> * What is your evaluation of the design?
>>
> 
> Not generic enough.  It addresses a number of specific problems (e.g. use in
> MT contexts, order-of-initialisation fiasco, etc) but the author's design
> choices are neither customizable nor overridable.  

> For instance, the design
> could be made more flexible by allowing thread-safety to be specified as a
> policy (with appropriate default) or by delegating the responsibility to the
> wrapped type.  

OK, FWIW policies complicate things. And what's their benefit here?

> If BOOST_HAS_THREADS is defined, it looks as though I have no
> choice but to use mutexed instantiation and/or access.  If I'm not
> interested in synchronised access, then the lease interface is useless.

Wrong:

The lease interface is useful to improves performance. The test whether
the Singleton has been initialized (which requires synchronization) can 
be performed only once.

> 
> The solution to the OOI problem does not scale, and I would go as far as
> saying that it doesn't work in practice.  In my experience, it's a constant
> maintenance nightmare to try and keep the various slot assignments in the
> correct order (I have to deal with a large number of singletons; yes that is
> a problem in and of itself - this library will do nothing to discourage
> it). 

You must have misunderstood the docs. OOI is not done with slots. The
slots are to prevent unnecessary resurrection during destruction.

>  The only scheme I've personally had any success with, so far, involves
> some form of reference counting, i.e. singletons that depend on other
> singletons do so explicitly (by incrementing the other's refcount on
> construction; the singletons are destroyed when their refcount goes to
> zero).

You might have gotten away with it in practice, but introducing this
kind of coupling seems really bad design to me.

> 
> Another reason why the proposed OOI solution fails in practice is that other
> singletons are not a singleton's only dependency: client code ( e.g. objects
> that reference the singleton) are dependencies as well and may affect the
> order of destruction.  

What is the "proposed OOI solution" you are talking about?

> You just can't assume the singleton manager will be
> the last thing to go - there may be other globals. 

It's the "we should remove pointers from C++ because one can dereference
NULL" kind-of argumentation.

> BTW I find the very idea
> of being able to "force" singleton destruction quite scary, but I haven't
> looked at the implementation details. 

It's necessary, as long as C++ runs on top of ABIs that don't support
code to be run automatically when a dynamic library is unloaded and I 
can assure you that running code in an unloaded, dynamic library is a 
lot scarier :-).

> The following sentence is also cause
> for concern: " Attempts to access an already destroyed Singleton instance
> cause the instance to be re-created."  Is that true only for DLL usage?

It's true in general.

> My biggest problem with this design is that it is unsuitable for library
> writers: types derived from typical singleton class designs, including
> boost::singleton and friends under review, invariably give rise to
> untestable code.  To make a singleton's client code testable involves
> exposing some kind of overridable factory so that the singletonized type can
> be replaced with a test mockup.  So far I have found this to be a hard
> problem to solve in general.

Interesting point.

> 
> Finally, this may constitute a minority opinion but I like to consider
> global access and single instance as orthogonal concepts.  One may want to
> ensure a resource is only instantiated once without necessarily providing
> global access to that resource.

So Singletons should be dynamic arrays in your opinion?

Regards,
Tobias