On Thu, 2008-09-04 at 11:56 +0200, Bernd Petrovitsch wrote:
> On Wed, 2008-09-03 at 13:45 -0400, Bob Keyes wrote:
> > On Wed, 3 Sep 2008, Sven-Ola Tuecke wrote:
> [...]
> > > mmh. CLOCK_MONOTONIC is not supported by uclibc AFAIK.
> > 
> > Are you sure? See: 
> > http://www.nabble.com/sysconf(_SC_MONOTONIC_CLOCK)--problem-td17807017.html
> 
> If I read
> http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/common/clock_gettime.c?rev=16821&view=markup
> correct, it depends if the Linux kernel (which the uClibc is compiled
> against) has a clock_gettime() syscall (and then the syscall is used) or
> not (and then just CLOCK_REALTIME is simulated via gettimeofday()).

In theory one could use that and - if clock_gettime(CLOCK_MONOTIC) is
EINVAL, use times(2) or whatever.
In practice, this implies that one must be converted into the other
since both deliver different results. And that will probably need
usually slow/expensive (assembler) muls/divs (and not "only" a few
shifts + adds/ors).

times(2) delivers number of clock-ticks (or more exact:
sysconf(_SC_CLK_TCK)) and clock_gettime(2) a struct with two signed long
ints - one for the seconds, the other for nano seconds.

Personally I find it too CPU and code-intensive (even if one uses nice
functions for it) to move 2 longs around and add/subtract always two
times just to handle timeouts shorter than 20 minutes .....

The only pro argument that sells IMHO is that poll(2) also accepts a
struct timespec. But is that it worth?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




