[olsr-dev] Question about implementation internals

[Andreas Tønnesen]

Here are just some quick comments:

Ignacio García Pérez wrote:
> Sorry, what does "signed" mean here ?

It was just me messing around with the idea that the time spent in the
scheduler loop value would never become negative if the values were
unsigned, but ofcause that would cause problems when subtracting the
value from the sleeptime.... ahh never mind :)
But the fix for this is no worse than checking that the time-spent value
is withing the interval [0 - sleep_interval] I guess. But then again,
this case was never the real problem.

> Correct me if I'm wrong: for a certain type of table, you insert new records
> at the end, meaning that they are always sorted and the first one is the one
> of earliest expiration. Then, for each check, you just have to start at the
> first entry and proceed removing entries until you find one whose expiration
> time is later that current time.

No. The tables are hashed and they are not reordered by validity time at
any point other than deletion and re-insertion.

> When not using pthreads, the timing mechanisms provided by linux are sleep,
> nanosleep, select, pselect, poll, and gettimeofday. All the calls take a
> timeout lapse as parameter, which is preferred since taking an absolute,
> system time as parameter would lead to race conditions upon system time
> changes. But of course, to get a current time reference, all you have is
> gettimeofday which returns system time. So if you use gettimeofday as a
> starting point to calculate timeout lapses, you are, in fact, getting the
> same race conditions. If you are not using calculations but comparisons (as
> OLSRD doeas according to your description), the problem is even worse, since
> you are almost guaranteed to be in trouble upon a system change, as opposed
> to a race condition which is supposed to happen very seldom. (now that I
> think about it, race conditions are in fact WORSE, since are harder to
> reproduce and thus to chase down).
> 
> 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?

I'll be studying the rest of your mail closer later on and discussing
this with Thomas - you are coming up with some very interesting points.
But right now I've gotta run. Have a nice sunday :)

- Andreas

-- 
Andreas Tønnesen
http://www.olsr.org