[olsr-dev] Question about implementation internals

[Ignacio García Pérez]

> > The funny thing is that all this would be solved if only there
> was a system
> > call that would return some sort of MONOTONIC clock, such as
> the uptime you
> > mention.
>
> Isn't this kindof what times(2) returns? I'm not sure here - but that
> was my initial idea for what to use if changing this... have you tried
> this?

Nope. I told you I'm certainly no unix guru. I feel *rather* stupid.
times(2) seems to do exactly what is required in this case. As you point out
in your next message, resolution is more than enough, and I doubt any other
mean of getting higher resolution would be of any help since you are
ultimately limited always by the kernel tick at 100Hz.

So, times(2) seems to solve the problem regarding olsrd. It is a monotonic
clock which is exactly what you need. The rest of this message is thus
off-topic, but nevertherless I would really like to head your opinion.

times(2) seems to be of no help at all in pthread programs that use
cond_timedwait. As I said, there will always be a race condition as long as
the system clock is used (indeed two race conditions since cond_timedwait
does an internal conversion to timeout lapse and for that is calls
gettimeofday()).

I guess the only solution is to get CLOCK_MONOTONIC as specified in POSIX
1003.1j implemented in glibc, and if necessary, patch the 2.4.x series
kernel I'musing to support it. I'll post a comment when find out more about
this matter. Yet I just can't believe how many programs out there contain
inherent race conditions.

Regards.

Nacho.



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 14/01/2005