[lkml]   [2007]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 14/22] pollfs: pollable futex
    On 5/1/07, Davi Arnaut <> wrote:
    > The pollable futex approach is far superior (send and receive events from
    > userspace or kernel) to eventfd and fixes (supercedes) FUTEX_FD at the same time.
    > [...]

    You have to explain in detail how these interfaces are supposed to
    work. From first sight and without understanding (all) the it seems
    it's far from useful.

    Pollable futexes are useful, but any solution which gets implemented
    must be sufficiently useful for all the uses we might have.

    - the trivial is that you have a futex and you are just interest in
    seeing it change. The
    same as FUTEX_WAIT. I cannot figure out how all this works in your
    code. Does your
    read() call (that's the one to wait, yes?) work with O_NONBLOCK or
    how else do you get
    that behavior?

    - more complicated case: I have to wait for multiple futexes and lock
    them all at the same
    time or don't return at all. This is possible with SysV semaphores
    and generally useful
    and needed. How can this be implemented with your scheme?

    - how does it work with PI futexes?

    - can I use a futex at the same time through this mechanism and using the normal
    FUTEX_WAIT operation? This is a killer if it's not the case.

    - if you have multiple threads polling a futex and the waker wakes up
    one, what happens?
    It is simply not acceptable to have more than one thread return from
    the poll() call, this
    would waste too many cycles, just to put all threads but one back to sleep.
    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: 2007-05-02 09:43    [W:0.020 / U:15.844 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site