[lkml]   [2001]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] /dev/epoll update ...

On 19-Sep-2001 Christopher K. St. John wrote:
> Davide Libenzi wrote:
>> 1) select()/poll();
>> 2) recv()/send();
>> vs :
>> 1) if (recv()/send() == FAIL)
>> 2) ioctl(EP_POLL);
>> When there's no data/tx buffer full these will result in 2 syscalls while
>> if data is available/tx buffer ok the first method will result in 2 syscalls
>> while the second will never call the ioctl().
>> It looks very linear to me, with select()/poll() you're asking for a state while
>> with /dev/epoll you're asking for a state change.
> Ok, if we're just disagreeing about the best api,
> then I can live with that. But it appears we're
> talking at cross-purposes, so I want to try this one
> more time. I'll lay my though processes out in detail,
> and you can tell me at which step I'm going wrong:
> Normally, you'd spend most of your time sitting in
> ioctl(EP_POLL) waiting for something to happen. So
> that's one syscall.
> If you get an event that indicates you can accept()
> a new connection, then you do an accept(). Assume it
> succeeds. That's two syscalls. Then you register
> interest in the fd with a write to /dev/poll, that's
> three.
> With the current /dev/epoll, you must try to read()
> the new socket before you go back to ioctl(EP_POLL),
> just in case there is data available. You expect
> there isn't, but you have to try. This is the step
> I'm talking about. That's four.
> Assume data was not available, so you loop back
> to ioctl(EP_POLL) and wait for an event. That's five
> syscalls. The event comes in, you do another read()
> on the socket, and probably get some data. That's
> six syscalls to finally get your data.
> ioctl(kpfd, EP_POLL) 1 wait for events
> s = accept() 2 accept a new socket
> write(kpfd, s) 3 register interest
> n = read(s) 4 <-- annoying test-read
> ioctl(kpfd, EP_POLL) 5 wait for events
> n = read(s) 6 get some data

You continue to put the state check ( ioctl() ) before the system call,
that require you to use select()/poll()//dev/poll interfaces that are
state inquiry interfaces.
The /dev/epoll is, like i said before, a state change notification interface.
That's how have been designed and that how it completely avoid fds scan.
If you're looking for a state inquiry interface it's better for you to seek /dev/poll.

- Davide

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.182 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site