lkml.org 
[lkml]   [2002]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] 'select' failure or signal should not update timeout
    Rusty Russell wrote:
    >
    > On Wed, 24 Jul 2002 11:48:10 -0700 (PDT)
    > Linus Torvalds <torvalds@transmeta.com> wrote:
    >
    > > The thing is, we cannot change existing select semantics, and the
    > > question is whether what most soft-realtime wants is actually select, or
    > > whether people really want a "waittimeofday()".
    >
    > NOT waittimeofday. You need a *new* measure which can't be set forwards
    > or back if you want this to be sane. pthreads has absolute timeouts (eg.
    > pthread_cond_timedwait), but they suck IRL for this reason.
    >
    > Of course, doesn't need any correlation with absolute time, it could be a
    > "microseconds since boot" kind of thing.
    >
    The POSIX clocks & timers API defines CLOCK_MONOTONIC for
    this sort of thing (CLOCK_MONOTONIC can not be set). It
    also defines an API for clock_nanosleep() that CAN use an
    absolute time which is supposed to follow any clock setting
    that is done. Combine the two and you have a fixed time
    definition.

    AND, guess what, the high-res-timers patch does all this and
    more.
    --
    George Anzinger george@mvista.com
    High-res-timers:
    http://sourceforge.net/projects/high-res-timers/
    Real time sched: http://sourceforge.net/projects/rtsched/
    Preemption patch:
    http://www.kernel.org/pub/linux/kernel/people/rml
    -
    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:27    [W:0.036 / U:0.240 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site