lkml.org 
[lkml]   [2006]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [take23 0/5] kevent: Generic event handling mechanism.
    Davide Libenzi a écrit :
    > On Thu, 9 Nov 2006, Eric Dumazet wrote:
    >
    >> Davide Libenzi a ?crit :
    >>> I don't care about both ways, but sys_poll() does the same thing epoll does
    >>> right now, so I would not change epoll behaviour.
    >>>
    >> Sure poll() cannot return a partial count, since its return value is :
    >>
    >> On success, a positive number is returned, where the number returned is
    >> the number of structures which have non-zero revents fields (in other
    >> words, those descriptors with events or errors reported).
    >>
    >> poll() is non destructive (it doesnt change any state into kernel). Returning
    >> EFAULT in case of an error in the very last bit of user area is mandatory.
    >>
    >> On the contrary :
    >>
    >> epoll_wait() does return a count of transfered events, and update some state
    >> in kernel (it consume Edge Trigered events : They can be lost forever if not
    >> reported to user)
    >>
    >> So epoll_wait() is much more like read(), that also updates file state in
    >> kernel (current file position)
    >
    > Lost forever means? If there are more processes watching some fd
    > (external events), they all get their own copy of the events in their own
    > private epoll fd. It's not that we "steal" things out of the kernel, is
    > not a 1:1 producer/consumer thing (one producer, 1 queue). It's one
    > producer, broadcast to all listeners (consumers) thing. The only case
    > where it'd matter is in the case of multiple threads sharing the same
    > epoll fd.

    In my particular epoll application, the producer is tcp stack, and I have one
    consumer. If an network event is lost in the EFAULT handling, its lost
    forever. In any case, my application do provide a correct user area, so this
    problem is only theorical.

    > In general, I'd be more for having the userspace get his own SEGFAULT
    > instead of letting it go with broken parameters. If I'm coding userspace,
    > and I'm doing something wrong, I like the kernel to let me know, instead
    > of trying to fix things for me.
    > Also, epoll can easily be fixed (add a param to ep_reinject_items() to
    > re-inject items in case of error/EFAULT) to leave events in the ready-list
    > and let the EFAULT emerge.

    Please dont slow the hot path for a basically "User Error". It's already
    tested in the transfert function, with two conditional branches for each
    transfered event.

    > Anyone else has opinions about this?
    >
    >
    >
    >
    > PS: Next time it'd be great if you Cc: me when posting epoll patches, so
    > you avoid Andrew the job of doing it.

    Yes, but this particular patch was a followup on own kevent Andrew patch.

    I have a bunch of patches for epoll I will send to you :)

    Eric
    -
    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: 2006-11-09 08:27    [W:4.914 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site