Take the 2-minute tour ×

I have a separate thread reading from a non-blocking socket that I am ok with using as much CPU as necessary since low-latency is the most important aspect of the project. Would it be faster to simply loop on a read() call than use a select() first to look for sockets that are readable?


while (!finished) {

    int rc = read(socket, buf);
    if (rc > 0) {
        // process buf
    } else if (rc == 0) {
        // eof, reconnect to server
    } else if (errno == EGAIN) {
        // nothing to do, continue
    } else if (errno == ECONNREFUSED) {
        // connection refused, attempt connect again
    } else {
        // error not yet supported
share|improve this question
If you're going to do that ... why wouldn't you just do a blocking read? –  Brian Roach Dec 16 '12 at 3:58
Agreed. Putting the read() in a separate thread means that it can block without stalling the rest of the application. Non-blocking I/O is only necessary if the thread needs to do other things when data isn't available on the socket. –  Barmar Dec 16 '12 at 4:38
Part of the thought process was the spinning thread would be less likely to be context switched than a blocking socket waiting on a read or a non blocking socket using select. –  mr19 Dec 16 '12 at 5:18
A spinning thread isn't usually good for latency; it's likely to hold off other threads and slow down the rest of the system... and if you're running under a dynamically-prioritizing scheduler (e.g. the default scheduler for Linux), a spinning thread will have its priority dynamically reduced (so that other threads get first dibbs to the CPU) and that will actually increase latency for your thread. So I agree with Barmar, you're better off using a blocking read (or even select() should be fine if you only have a few sockets registered in it). –  Jeremy Friesner Dec 16 '12 at 8:40
Note that if you really want low latency, a better approach is to raise your thread or process's priority (e.g. under Linux, using sched_setscheduler() with a SCHED_RR or SCHED_FIFO argument), or even switching to a hard-real-time OS like Xenomai or VxWorks that will make latency guarantees for you. –  Jeremy Friesner Dec 16 '12 at 8:43

1 Answer 1

No it wouldn't be faster, because you don't know when the data is going to arrive. So, either you will sleep for too long, which isn't faster, or you will sleep for too short, in which case you have to so it all again, which isn't faster, or you will get lucky and sleep for exactly the right time, which isn't faster and requires luck, or you won't sleep at all, which means you have to burn the CPU until the data arrives, which also isn't faster.

share|improve this answer
He never said anything about sleeping. –  Barmar Dec 16 '12 at 4:36
@Barmar Which comes under the heading of 'won't sleep at all'. What I have done here is enumerate all the possibilities (except using blocking mode, which is what he should be doing). –  EJP Dec 16 '12 at 8:41
This thread has a dedicated core so burning cpu didn't seem to be an issue for me. Between that and not performing a select or blocking read I hoped to prevent the thread from being switched out. –  mr19 Dec 16 '12 at 11:01
It still won't be faster in any way you can actually measure. The limitation of the network bandwidth is orders of magnitude more significant than scheduling effects. –  EJP Dec 16 '12 at 23:23

Your Answer


