[lkml]   [2002]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [rfc] epoll interface change and glibc bits ...
    On Tue, 19 Nov 2002, Edgar Toernig wrote:

    > Davide Libenzi wrote:
    > >
    > >
    > >
    > >
    > >
    > >
    > > it is going to change though with the latest talks about the interface.

    Yes, man pages needs some work after the interface will be fixed. I hope
    to fix it this week.

    > Remove the waitqueue stuff from epoll.2. It has meaning only to
    > linux kernel developers and noone else.

    Sigh, I liked it :)

    > What about adding an fd twice to the epoll-set? Do you get an
    > error, will it override the previous settings for that fd, will
    > it be ignored, or is it registered twice and you get two results
    > for that fd?

    You get EEXIST
    Well, there's the remote possibility, trying very badly from two threads,
    to add the same fd twice. It is an harmless condition though.

    > Can two epoll-sets wait for the same fd?

    Yes. Not suggested though.

    > Are events reported to both epoll-fds?


    > Is the epoll-fd itself poll/epoll/selectable?


    > Can I build cluster of epoll-sets?

    Uh ?!

    > What happens if the epollfd is put into its own fd set?

    You might find your machine a little bit frozen :)
    Either 1) I remove the read lock from poll() or 2) I check the condition
    at insetion time to avoid it. I very much prefer 2)

    > Can I send the epoll-fd over a unix-socket to another
    > process?

    I'd say yes. SCM_RIGHTS should simply do an in-kernel file* to remote task
    descriptor mapping.

    > Then, please add more details of how events are generated. You
    > say, that an inactive-to-active transition causes an event. What
    > is the starting point of the collection? (I guess, all transitions

    The starting point are the bits found at insertion time.

    > between two epoll_wait calls.) There could be a couple of transi-
    > tions on an fd between two epoll_wait calls. Are these events com-
    > bined into a single reported event or is each single edge reported?

    Yes, they'll be combined.

    > Does an operation on an fd effect the already collected but not yet
    > reported events?

    You can do two operations on an existing fd. Remove is meaninless for this
    case. Modify will re-read available bits.

    > About epoll_wait: it looks like a "read with timeout" call. Is that
    > really necessary or wouldn't a normal read(2) work as well? Similar
    > for epoll_ctl: couldn't a write(2) to the epoll-fd do the same?

    IMHO distinc functions are more clear than magic read/write operations.

    - 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:31    [W:0.027 / U:13.380 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site