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