[Olsr-dev] OLSR Basic Multicast Forwarding (BMF) plugin v1.6.1available

[Erik Tromp]

> Maybe we should include the locking semaphore into the main branch. 
> Overwriting files of the main branch from a plugin is a bad 
> idea because it's very dependent on the version of the main branch.

Don't worry: there is a separate version of BMF for various versions
of OLSR.


> In addition to this I would do the modified 
> olsr_scheduler_sleep a little bit different to prevent 
> starvation of the utility threads.
..
>   /* While sleeping, other threads may use the OLSR data */
>   pthread_mutex_unlock(&olsr_mutex);
> 
>   if (timercmp(&time_used, &next_interval, <)) {
>     timersub(&next_interval, &time_used, &sleeptime_val);
> 
>     sleeptime_spec.tv_sec = sleeptime_val.tv_sec;
>     sleeptime_spec.tv_nsec = sleeptime_val.tv_usec * NSEC_PER_USEC;
> 
>     while (nanosleep(&sleeptime_spec, &remainder_spec) < 0)
>       sleeptime_spec = remainder_spec;
>   }
>   /* Grab the mutex as soon as we wake up again */
>   pthread_mutex_lock(&olsr_mutex);
> }

Putting the mutex grab/release outside the if-statement is
possible, but it doesn't really affect the behaviour, I would
think. The most important is that the grab/release is outside
the while-statement.



> Maybe we could think about an infrastructure in the scheduler 
> that would allow plugins like the bmf to use the olsr 
> mainloop instead of a thread of it's own ?

I agree, but... for a fast response to incoming packets, BMF uses a
call to select ("man 2 select"). That will return as soon as a packet
is received (synchronously). Using a polling mechanism to wait for
incoming packets would not be my preference. Or do you perhaps know a
way have a single thread to wait synchronously for "either a socket
file descriptor, or a timer expiry"?