Mark Mielke wrote:

>Not to enter into any of the other discussions on this issue, I wouldn't
>usually do what you suggest above. [...] if I did I
>a recv() or read() of 2K, and I only received 1K, there is no reason why
>another system call should be invoked on the resource that likely will not
>have any data ready.
>  
>
You're into the minutiae here.  Sure, you can optimize the read() in 
some cases, but Mr. Libenzi's example of a correct code scheme is no 
better than mine when it comes to this.

In some situations, I've found that optimizing in the other direction is 
useful.  When a peer is feeding you data slowly you can increase 
throughput by having the thread block on read for a couple of 
milliseconds before going back to the pool.  A large part of that was 
that the particular event delivery subsystem was expensive.