[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: FW: [RFC] A more general timeout specification
    >From: Roman Zippel []
    >On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
    >> Usefulness: (see the rationale in the patch), but in a nutshell;
    >> most POSIX timeout specs have to be absolute in CLOCK_REALTIME
    >> (eg: pthread_mutex_timed_lock()). Current kernel needs the timeout
    >> relative, so glibc calls the kernel/however gets the time, computes
    >> relative times and syscalls. Race conditions, overhead...etc.
    >> This mechanism supports both. That's why it is more general.
    >Your patch basically only mentions fusyn, why does it need multiple

    I cannot produce (top of my head) any other POSIX API calls that
    allow you to specify another clock source, but they are there,
    somewhere. If I am to introduce a new API, I better make it
    flexible enough so that other subsystems can use it for more stuff
    other than...

    >Why is not sufficient to just add a relative/absolute version,
    >which convert the time at entry to kernel time?

    ...adding more versions that add complexity and duplicate
    code in many different places (user-to-kernel copy, syscall entry
    points, timespec validation). And the minute you add a clock_id
    you can steal some bits for specifying absolute/relative (or vice
    versa), so it is almost a win-win situarion.

    To summarize: thought about that, but it is fugly and not too practical.

    Consider also his allows you to write extensions to POSIX or your
    own user-level APIs that could allow (following the fusyn example)
    you to wait on a mutex with a timeout based off a monotonic clock,
    if you need it (or something that makes more sense than this--highres
    comes to mind).

    -- Inaky
    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: 2005-09-01 01:28    [W:0.021 / U:171.176 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site