Now I’m in such a situation that there is a group of predefined tasks for multiple clients to do(any client can take any task). When a client connects to the server, server choose a task from the uncompleted tasks and send it to the client — job on the server side is quite easy. It takes a while for the client to finish the task and send the result back to the server.
Since a task should be sent to only one client, server should process requests in a serialized way. Now I have two plans to do it: create a thread for each client connection and all the threads take turns accessing the task pool, or use epoll listening on all the connection and process for each event of clients.
Which one is better for the job? Or is there any other ideas? The server will be run on a multi-core machine.
The main question is whether the server has significant processing to do in order to prepare the tasks for the client. If not, there’s nothing to be gained from using multiple threads — on the contrary, the context switching will just add overhead. In this case it would be the best to use
epoll(most likely via some existing library, depending on the programming language you’re using).If there is significant processing on the server side, it may offset the inefficiency of context switching, and improve performance by gaining parallelism from multiple core. The only way to know for sure what the best solution will be is to do some prototyping and profiling.
Are the clients running on the same machine as the server is?
If they are, you’ll be able to utilize the multiple cores easily.