lkml.org 
[lkml]   [2002]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Futex Asynchronous Interface
    Rusty Russell wrote:
    > In message <Pine.LNX.4.44.0206110951380.2712-100000@home.transmeta.com> you wri
    > te:
    >
    >>Rusty,
    >> this makes no sense:
    >>
    >>D: This changes the implementation so that the waker actually unpins
    >>D: the page. This is preparation for the async interface, where the
    >>D: process which registered interest is not in the kernel.
    >>
    >>Whazzup? The closing of the fd will unpin the page, the waker has no
    >>reason to do so. It is very much against the linux philosophy (and a
    >>design disaster anyway) to have the waker muck with the data structures of
    >>anything waiting.
    >>
    >
    > Good catch: now the fd is a "one-shot" thing anyway, making close
    > unpin the page makes more sense. Tested patch below (against 2.5.21).
    >
    > FYI: I already violate this philosophy as I remove the waiter from the
    > queue when I wake them: this allows them to tell that they were woken
    > (waker does a list_del_init() on the waiting entry, so waiting knows
    > if (list_empty()) I was woken).
    >
    > It would be more natural for the waiter to examine the futex value,
    > and if it's still unchanged go back to sleep. But this makes
    > assumptions about what they're using the futex value for. For
    > example, we "PASS_THIS_DIRECTLY" value into the futex. This requires
    > that one (and ONLY one) process waiting actually wakes up.
    >
    > This is why coming up with a primitive which allowed us to build posix
    > threads and fair queueing as well as "normal" unfair semantics took so
    > damn long.
    >

    What are the plans on how to deal with a waiter when the lock holder
    dies abnormally?

    What about sending a signal (SIGTRAP or SIGLOST), returning -1 and
    setting errno to a reasonable value (EIO?)

    I couldn't find anything in susv3


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