Singleton/Multiton Longevity
Just a status update on the singleton/multiton library, so that people know I am still alive ;). After much chaos trying to write a multiton longevity lifetime policy, I had the sudden realization that both singletons and multitons should be able to play nicely together. Thus, I am writing a single(ton) class to manage a priority queue of shared_ptrs to nodes. The longevity policies will derive privately from their respective dependency policies, and create their own derived node types which hold dependencies. As the inheritance is private, these will be the only dependencies in existence. Both multitons and singletons will be destroyed as the dependency-holding nodes are popped in the destructor of the instance registry, which itself will have a static dependency to ensure existence for the entire lifetime of the program. Thoughts and suggestions, as always, are welcome. -Jason
Jason Hise wrote:
Just a status update on the singleton/multiton library, so that people know I am still alive ;). After much chaos trying to write a multiton longevity lifetime policy, I had the sudden realization that both singletons and multitons should be able to play nicely together. Thus, I am writing a single(ton) class to manage a priority queue of shared_ptrs to nodes. The longevity policies will derive privately from their respective dependency policies, and create their own derived node types which hold dependencies. As the inheritance is private, these will be the only dependencies in existence. Both multitons and singletons will be destroyed as the dependency-holding nodes are popped in the destructor of the instance registry, which itself will have a static dependency to ensure existence for the entire lifetime of the program.
Thoughts and suggestions, as always, are welcome.
Jason, I'm playing here with some child_process code and have a singleton class that monitors the status of all the child processes using waitpid/WaitForSingleObject. I was thinking that I need a sort of Zombie policy rather than a Phoenix policy for my singleton. Ie, if its deleted and then called again it should be resurrected but flagged as dissabled. There's no need for it to go on to inform the rest of the (possibly/probably dead) program that a child process has just exited. Does that make sense? Could you add this to your list of available policies? I'm out of town for a week. Will respond to any answers you give thereafter. Regards, Angus
Angus Leeming wrote:
Jason,
I'm playing here with some child_process code and have a singleton class that monitors the status of all the child processes using waitpid/WaitForSingleObject.
I was thinking that I need a sort of Zombie policy rather than a Phoenix policy for my singleton. Ie, if its deleted and then called again it should be resurrected but flagged as dissabled. There's no need for it to go on to inform the rest of the (possibly/probably dead) program that a child process has just exited.
Does that make sense? Could you add this to your list of available policies?
I'm out of town for a week. Will respond to any answers you give thereafter.
Regards, Angus
Excellent idea! Your suggestion gave me an idea for a more general solution... an allocator which is templated with two other allocator types, and uses the first on the first allocation and the second on any subsequent allocation. Thus, the first allocator could alloc using new, or malloc, or statically, however you please, and the second could throw an exception, return null, or maybe just call a different constructor entirely. For your case in particular, I am providing a BoolAllocator, which just passes a boolean flag to the ctor. You might use such a policy as follows: class Zombie : public Singleton < Zombie, /*Selected Lifetime Policy*/ < /*other stuff*/, OneTimeAlloc < BoolAlloc < true > :: Allocator, BoolAlloc < false > :: Allocator > :: Allocator > { private: bool dead; protected: Zombie ( bool invalid ) : dead ( invalid ) { } ~ Zombie ( ) { } void foo ( ) { if ( !dead ) { /*do work here*/ } } } -Jason
participants (2)
-
Angus Leeming -
Jason Hise