Re: [PATCH] 'select' failure or signal should not update timeout

[george anzinger <george@mvista.com>]

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