Socket.Select, blocking read / performance
Hi,
I have two questions regarding performance reading from a TCP socket. I am trying to minimize the latency on reading from the socket.
1. Assuming I have an application which reads data from one TCP socket in a dedicated thread, is there any difference between using blocking Read from socket and using Select?
2. Assume a multithreading application. When there is no data available to read on the socket, Select blocks the thread execution. What kind of block is this in terms of scheduling? When data become available, what exactly happens? I suppose the scheduler will need to context switch back to the thread which called the Select method, and that is going to take some time, especially when other threads are under heavy load (doing some computations). I wonder what I can do to minimize the latency between when the data is available on the TCP stack and when the thread wakes up to actually read the data. My measurements (using timestamps in the message payload) show that usually I am able to pick up the data from the socket quickly (under 1 ms), but sometimes it's 5 ms, 10 ms, 14 ms, which is bad for my application.
Any ideas welcome.
