Messages in this thread |  | | | Date | Wed, 16 Oct 2002 16:48:32 -0700 | | From | John Gardiner Myers <> | | Subject | epoll (was Re: [PATCH] async poll for 2.5) |
| |
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.
[unhandled content-type:application/x-pkcs7-signature] |  |