epoll (was Re: [PATCH] async poll for 2.5)

From: John Gardiner Myers (jgmyers@netscape.com)
Date: Wed Oct 16 2002 - 18:48:32 EST


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.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:30 EST