lkml.org 
[lkml]   [2002]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [rfc] epoll interface change and glibc bits ...
    Date
    >>>>> Mark Mielke <mark@mark.mielke.cc> writes:

    >> OTOH, I really hate the "user pointer in struct epollfd" thing...

    > Are you saying you see no way of using the 'user pointer in struct
    > epollfd' to accelerate event dispatching?

    No, I'm saying that's it's a tricky and unusual thing, and I'm not
    convinced that eliminating an fd array will make a substantial
    difference, cache or no.

    > For a perfectly good example of a use for it that has nothing to do
    > with pointers, consider the possibility that the structure could
    > hold a priority number [...] to sort high priority events before low
    > priority events without having to dereference every single fd?

    Sure, but...

    > I would even tend to delay executing low priority events until
    > epoll_wait(0) stopped telling me about high priority events.

    ...for this to work, you have to stow events over epoll calls. The
    sensible place to store these is in your per-fd structure. So you
    still don't save the access to your per-event structure, just the one
    array index lookup.

    If you do priorities, you *must* do this; otherwise you will be
    processing all events as they arrive in userspace. Merely doing them
    in priority order will produce a slightly reduced but still O(n)
    latency for high priority events, rather than roughly bounded latency
    as is usually the intent.

    BTW it is also possible to implement event prioritization in
    kernelspace. You just [e]poll several sets of epolled fd's and take
    the most interesting set of events each time. Unless, that is, the
    new syscall interface broke this...

    > An opaque field gives me, the event loop designer, freedom. No
    > opaque field because a few event loop designers are convinced that
    > it will be used as a data pointer, and they believe this to be
    > wrong, is a limitation.

    Bah. Freedom causes holes in feet.

    Flexible interfaces are invariably a pain for the users or the
    developers or both. Inflexible interfaces are less painful - they
    either work or they don't. As long as you avoid the nonworking sort,
    life is wonderful.

    > epoll provides a very efficient alternative to poll. Forcing epoll
    > to look like poll somewhat defeats the purpose. I don't mind having

    No argument here; it might even be handy for epoll to do other things,
    but this hinting feature just feels wrong. (Even "other things" would
    probably be better implemented through standard poll or some other
    non-specialized mechanism).

    To the coder go the spoils; we'll see what Davide does. And what
    Linus lets in...

    --
    Grant Taylor - gtaylor<at>picante.com - http://www.picante.com/~gtaylor/
    Linux Printing Website and HOWTO: http://www.linuxprinting.org/
    -
    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:31    [W:0.021 / U:89.596 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site