Hi,
When I switched to batman, I saw that times() is used in it as well, so I made the patch attached. So, if anyone sees packets fail to come from batman for 40 seconds, they might need this.
excellent finding! I immediately applied your patch.
For the curious reader: When you develop a daemon that should do certain things in intervals (e.g. sending packets, removing dead nodes from the routing table, etc) you will need a reference clock to know when this interval is over. Using the system time as reference is the obvious solution which theoretically offers what you need.
As often, reality is much harder: time synchronisation approaches (e.g. NTP), manually changed system time, winter / summer time switches, timezones, etc might encourage the daemon to improvised reactions (e.g. sending the messages of the last 3 years because ntp just finished the time sync).
A more stable reference clock can be found by using the times() system call. It returns "the number of clock ticks that have elapsed since an arbitrary point in the past" (often the uptime). The compelling advantage: it always increments although it overflows from time to time.
Batman uses the times() function which has a bug that this patch deals with. I had a short look in the olsr code (0.5.6-r4) to see how this bug is being handled there. main.c line 896 reveals a function called olsr_times()
--- SNIP --> clock_t olsr_times(void) { struct tms tms_buf; return times(&tms_buf); } <-- SNAP ---
which is called from vairous places that don't deal with this bug:
scheduler.c line 117 --- SNIP --> void olsr_scheduler(void) { [..] /* Main scheduler loop */ for (;;) {
/* * Update the global timestamp. We are using a non-wallclock timer here * to avoid any undesired side effects if the system clock changes. */ now_times = olsr_times();
[..]
/* We are done, sleep until the next scheduling interval. */ olsr_scheduler_sleep(olsr_times() - now_times); <-- SNAP ---
Regards, Marek