lkml.org 
[lkml]   [2002]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] epoll more scalable than poll
    On Mon, 28 Oct 2002, Jamie Lokier wrote:

    > Davide Libenzi wrote:
    > > sys_epoll, by plugging directly in the existing kernel architecture,
    > > supports sockets and pipes. It does not support and there're not even
    > > plans to support other devices like tty, where poll() and select() works
    > > flawlessy. Since the sys_epoll ( and /dev/epoll ) fd support standard polling, you
    > > can mix sys_epoll handling with other methods like poll() and the AIO's
    > > POLL function when it'll be ready. For example, for devices that sys_epoll
    > > intentionally does not support, you can use a method like :
    >
    > :( I was hoping sys_epoll would be scalable without increasing the
    > number of system calls per event.
    >
    > Is it too much work to support all kinds of fd? It would be rather a
    > good thing IMHO.
    >
    > I'm thinking that a typical generic event handling library (like in a
    > typical home grown server) takes a set of fds and event handling
    > callbacks. sys_epoll is obviously not so trivial to use in place of a
    > poll() loop, because the library needs to fstat() each fd that is
    > registered to decide if epoll will return events for that fd.
    >
    > For that to work, it's important that you can determine, through
    > fstat(), whether sys_epoll will actually return events for the fd, or
    > whether a sigqueue event is needed to trigger the epoll read.
    >
    > So, is it exactly _all_ sockets and pipes, and nothing else?
    >
    > Btw, is the set of fd types supported by epoll the same as the set of
    > fd types supported by SIGIO? That would be convenient - and logical.

    Jamie, doing that is not a real problem. The fact is that sys_epoll aimed
    to solve issues where scalability on huge number of fds is involved. By
    covering sockets ( network connections ) and pipes ( cgi execution ) you
    have a pretty wide scalability addressing. Usually you know from where and
    fd born, so you're typically able to handle it correctly. Those reasons,
    togheter with the fact that I did not want to introduce revolutions in the
    kernel, drove me to limit the sys_epoll coverage to sockets and pipes.



    - 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:30    [W:4.800 / U:0.188 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site