lkml.org 
[lkml]   [2007]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 14/22] pollfs: pollable futex
    On Wed, 2 May 2007 01:08:26 -0700
    "Ulrich Drepper" <drepper@gmail.com> wrote:

    > On 5/2/07, Eric Dumazet <dada1@cosmosbay.com> wrote:
    > > Well, poll() level edge semantic is well defined, you cannot cheat or change it.
    > >
    > > If many threads call poll() on the same end point, they should *all* return POLLIN/whatever status.
    >
    > This means to me it's the wrong abstraction for this. We had a nice
    > solution for this with Evgeniy's kevent interfaces. It worked without
    > forcing futexes is this inflexible poll() interface.

    poll() is a generalist interface. Not the *perfect* one, but well spreaded on other OS as well.

    >
    >
    >
    > > This is why programs usually use one thread to dispatch events to workers, or at least dont queue XXXX threads calling poll() on one fd.
    >
    > No. This is why programs are forced to waste cycles by doing this.
    > Ideally this would not happen. Ideally you'd park all worker thread
    > in the same place and have them woken up one by one. Again, Evgeniy's
    > code was able to do this. This approach seems to be a big step
    > backward.

    I understand your concerns, but *this* patch bundle extends poll()/select()/epoll, and is not an alternative to kevent or other work in progress, (and linux centered)

    Are you suggesting poll() system call should be deprecated ?

    Most programs still use the archaic select() thing you know ...

    -
    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: 2007-05-02 10:53    [W:7.547 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site