Re: [boost] singleton_ptr

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-07-17 15:11:54

On Sat, 16 Jul 2005 14:21:34 -0400, Jason Hise wrote
> Background:
> Since the first version of my singleton library was rejected, 

Happy to hear you're still working on this :-)

> I have 
> been designing a new singleton library from the ground up.  I feel 
> that this is necessary because the first version was not designed 
> with the concerns of threading in mind, and such concerns cannot 
> easily be addressed efficiently as an afterthought.  

This sounds a bit drastic.  I'm sorry I didn't have time to follow the review
in detail, but I would imagine that much of the interface was perfectly fine. 

>The new design  should hopefully be able to handle threading 
>effectively without introducing any overhead for the single 
>threaded model.

Excellent.

> Question:
> With the new design, I am adding a policy to control exactly what 
> happens if creation is attempted while the singleton instance 
> exists.  The options thus far include throwing an exception, doing 
> nothing, or destroying and recreating the singleton, depending on 
> the policy used.  

I can't imagine wanting a client wanting an exception if a 'race condition'
with multiple threads leads to several clients needing the singleton.  I also
don't think destroy and recreate makes much sense -- that would invalidate the
reference of the first client. Why not just simplify and  return the already
created singleton in all cases?

> Does it make sense to have a similar policy for 
> what happens when attempting to destroy an already destroyed 
> instance?  I can think of a few options that would make sense, such 
> as doing nothing, throwing an exception, asserting, or creating the 
> instance so that it can be re-destroyed, but I do not know if these 
> would actually be useful enough to justify a point of customization. 

Seems doubtful to me.

Jeff