In the book Linux Networking Programming three methods are discussed for server architecture.
Multiplexing - a listen socket is created then using select on a set of socket discriptors a set with active sockets is returned. We then iterate through the set, if it is the listen socket we accept a child socket and add the child socket discriptor to the main watched set. If it is a childsocket we process the request for the childsocket. This is all sequential testing each socket discriptor in the active set and then processing.
In the process pool we use fork which creates a pool that each wait to accept child sockets on the listen socket.
The multithreaded is similar creating a pool of threads that accept clients each thread blocking until a connection occures.
(This method shares resources unlike the process method.)
It then makes a little comment about combing these methods but gives no example.
While both the thread pooling method seems efficient you have a bunch of dead threads waiting on client connections. Would it be better to use select on the listing socket and spawn a single thread when there is activity over pooling multiple threads?
Second assuming a child socket is created using accept. It seems to me their is no guarantee somthing is there to be read from the socket. So should I use multiplexing and add the new socket to the watch set the test the set for activity. Or can I assume there is somthing to be read if a client is connecting.
The gist of this thread is I am a little confused about combing these methods.
For a simple chat app preforking would not be good because new clients would not be visible to all processes unless I used specific resource sharing techniques across processes which I dont know who to do. If I had say 256 clients a thread pool may eat up all my resources, before the max clients connected. Multiplexing polls the socket discriptors for activity but if the thread handles a new connection and processes the request there is no further need for polling hence part of my confusion