Here are my points:

1. There is a difference between having only one instance of the object in the entire application vs. an object becoming singleton so that any one calling new() will magically find theInstance.

2. In your case, there is no benefit of having server being singleton because no one is creating server other than main(). It's just plain simple to have it as ordinary object. Even if it is singleton, it will be called only once!

3. Parser should never be singleton either for a different reason here. If i understood correctly, parser's only role is when core is launched; Ideally it should follow use-and-throw oattern rather than singleton

4. Even parser continues to serve some specific queries till core wants it, by design parser should be one instance per core because same instance of parser should never share information about various different cores. It makes parser dedicated per core.

5. Most people design logger as a singleton. It is not really much big deal, however, if you are a multi-threaded system a singleton logger is a big villien. First off, every singleton needs to be threadsafe. Suppose even if you make it thread safe, every time a thread x calls logger it is busy doing printf for thread y so as a result thread x waits where as ideally you should be worrying about getting the maximum out of your quad-Core system and serve as many request as possible.

6. Ideally only genuine case where logger should be centralized or singleton is where exact order of events must be registered one-by-one. For most purposes, different files and messages with its own time stamps are usually better even for debug as well.

So for me Server (which is one instance) is created by main() and core, parser and logger are a tuple borns and dies on per request (always together). Each tuple doesn't know the state or existence of other such tuple and that is good so that arbitrary number of threads can be instantiated in parallel, (one thread per tuple) without loosing scalability but preserving loose coupling.

Only thing is - it means you are not using any design pattern! But that's not a bad thing. It is not necessary that including a design pattern makes your design necessarily better.

Remember:

There are really rare reasons where using singleton becomes must; everywhere else, using singleton is always an invitation to problems.

Here are my points:

1. There is a difference between having only one instance of the object in the entire application vs. an object becoming singleton so that any one calling new() will magically find theInstance.

2. In your case, there is no benefit of having server being singleton because no one is creating server other than main(). It's just plain simple to have it as ordinary object. Even if it is singleton, it will be called only once!

3. Parser should never be singleton either for a different reason here. If i understood correctly, parser's only role is when core is launched; Ideally it should follow use-and-throw pattern rather than singleton

4. Even parser continues to serve some specific queries till core wants it, by design parser should be one instance per core because same instance of parser should never share information about various different cores. It makes parser dedicated per core.

5. Most people design logger as a singleton. It is not really much big deal, however, if you are a multi-threaded system a singleton logger is a big villain. First off, every singleton needs to be threadsafe. Suppose even if you make it thread safe, every time a thread x calls logger it is busy doing printf for thread y so as a result thread x waits whereas ideally you should be worrying about getting the maximum out of your quad-Core system and serve as many requests as possible.

6. Ideally the only genuine case where logger should be centralized or singleton is where the exact order of events must be registered one-by-one. For most purposes, different files and messages with their own timestamps are usually better even for debugging.

So for me Server (which is one instance) is created by main() and core, parser and logger are a tuple that is born and dies per request (always together). Each tuple doesn't know the state or existence of other such tuples, and that is good so that arbitrary number of threads can be instantiated in parallel, (one thread per tuple) without losing scalability but preserving loose coupling.

Only thing is - it means you are not using any design pattern! But that's not a bad thing. It is not necessary that including a design pattern makes your design necessarily better.

Remember:

There are really rare reasons where using singleton becomes must; everywhere else, using singleton is always an invitation to problems.