lkml.org 
[lkml]   [2001]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 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/

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