Thanks for all of the advice.
1. I'm pretty sure creation of many processes is not allowed.
I'll check though. It seems like creating a process to handle
a request is much more overhead than a thread though.
That depends on the OS; it often is (but doesn't necessarily
have to be). I suspect that the main reason HTTP servers, like
Apache, use threads instead of processes is performance
considerations, however; HTTP does result in a very large number
of very short lived connections, and maintaining a thread pool
can be a definite performance gain in such cases, at least on
many OS's. IMHO, however, it's an optimization measure: a
compromise of good design forced by performance considerations.
Since you're talking of a school project, and pthreads was
mentionned, it's likely that using processes instead of threads
would defeat the purpose of the exercise. But do be aware that
it's often a preferrable alternative.
2. Thats disturbing news about the discouraging comments on
singletons. I wish i had known that before I used so many in my
project already. I have a Logger(), Socket() and UI() singleton
classes, that basically offer static methods to do their job.
Logging management is a typical example of where a singleton is
usually the best solution. Another example would be
configuration management. On the other hand: each connection
will end up with its own socket, so that definitly cannot be a
singleton, and it's probably preferable to be able to support
multiple user interfaces. Unless the user interface is just the
command line and a configuration file---often the case with
servers, since they are started disconnected from any terminal
(but even then, the may provide a separate socket interface to
connect a manager interface to them).
I thought the singleton approach was a good idea because I
would never need more than one instance of these things,
The question isn't whether you will ever need more than one; the
question is whether by design, there cannot exist more than one.
For example, by definition, you can only have one logging
manager, and only one configuration manager.
and this way they can be accessed from any other object in the
program. For example i have a static Logger::log() that i can
use to log a message from any other object in the code now.
I'll look into why the singleton approach is a bad one, but I
wouldn't mind some insight here as well.
It's not intrinsically bad. It is very overused, however.
As for thread pools, Is the basic idea to create a group of
threads, then have them wait on a condition variable? In my
case, when the server gets a request, it would notify the
sleeping threads with a cond_var, the first thread to then
grab the mutex would handle the request. This approach seems
faulty, as only one thread would ever be able to grab that
mutex and run at any given time.
The thread shouldn't keep the mutex. The usual solution is to
use some sort of a message queue: the connection manager puts a
message with the connection socket id into the message queue,
and the server threads read from it. The mutex is only held
long enough to extract the message from the queue. (It's less
that 20 lines of code, using std::deque for the queue.)
. The current mode seems to use threads for