Question

my server uses non-blocking socket multiplexing.
I want to use one thread for receiving incoming connections and handle input and another thread for sending data over sockets. It will look like that:

reader_worker(...)
{
    ...
    select(fd_max+1, &read_set, NULL, NULL, NULL);
    ...
}

writer_worker(...)
{
    ...
    select(fd_max+1, NULL, &write_set, NULL, NULL);
    ...
}

Since I don’t want to miss incoming connections I can imagine it is better to receive and send in seperate threads. Do I have to lock the socket which might be in read_set as well as in write_set? Is this the correct approach or doesnt this method have any performance improvement?

Answer 1

You’re not going to miss any incoming connection if you do it in one thread. Even if you have large amounts of data to send or receive, the latency of a send() or recv() call is determined by the size of local buffers in the network stack rather, so you will be back quickly to accept incoming connections.

Two thing though, where I’m not sure about your code samples:

• Put the socket for accepting connections into the same array as the accepted connections for use in a single select() call. Unless you bind to different network interfaces, using multiple threads is not going to make you program run faster.
• If you are handling incoming data, this is where a second thread becomes useful. In general, you have resources like you network interface card, CPU, hard disk. It is useful to have one thread per resource, i.e. one to handle network IO (receiving requests, sending responses) and a second one to handle the actual requests. If you have multiple cores, you can also make use of multiple threads for handling requests, provided that is a CPU-bound task. If all that these requests do is serving pictures from a single hard disk, using more than one thread for requests won’t give you any additional performance.