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