Just from looking at that single post and its title, I believe you misunderstood the discussion/conclusion in that thread.

When the kernel people speak of "breaking" select(), they mean altering the behavior of their select() implementation. The topic of that debate seems to be whether a select() hit on a blocking socket GUARANTEES that a subsequent recvmsg() call will not block. It doesn't guarantee that, but most programmers expect it to, hence the question of whether it is right for select() to "lie" about state.

However, select() is better thought of as a temporary snapshot of I/O state. If select() indicates readability on a file descriptor, that does not mean that a subsequent read operation is guaranteed not to block.

Likewise, if stat() indicates that a file is 1363 bytes big, that does not mean that a subsquent open() + read() will be able to retrieve 1363 bytes from it because the file may have been deleted or resized in the meantime.

-------------

As for the original problem:

As others have stated, I also believe that you should make sure you are really measuring the right thing. It is highly unlikely that select() doesn't behave "as advertised".

Make sure that your gettimeofday() calls only measure select(). Perhaps you didn't just measure select() but also time for reading and processing data?

When you used gettimeofday() to record time, did you also make sure to use those same data structures when printing the time difference? How did you print it - did you maybe mix up seconds and microseconds? Are you sure your print statements aren't adding any extra delay because you didn't flush or unbuffer your output file?

Please post your real code. What you posted originally does not contain the gettimeofday() calls you said you used to measure it.

jim mcnamara's suggestion to trace the process is also good - If possible, run your program through "strace ./prog" and see whether it really spends a long time in select().