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.
On Wed, 16 Oct 2002, John Gardiner Myers wrote:
> 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.
The poll()-like code :
int my_io(...) {
if (poll(...))
do_io(...);
}
The epoll-like code :
int my_io(...) {
while (do_io(...) == EAGAIN)
event_wait(...);
}
I would say that the epoll-like code generates less system calls because
if you call my_io() by processing small chunks of the I/O space, the
epoll-like code will generate only one system call while the poll()-like
code two. In case of I/O that ends up in wait the poll()-like code
generate two system calls while epoll-like code three. Globally the number
of system calls are about the same and from a performance point of view
/dev/epoll looks "pretty good" ( see /dev/epoll page ).
- Davide