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

[Henning Rogge]

Am Dienstag 29 Juli 2008 12:17:39 schrieb 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.
It's still a source for bugs... especially as soon as we release bugfixes for 
a olsrd version.

> > 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.
Yes, it does...
Imagine the case that olsrd has too much to do, so it never sleeps because the 
handling of routing/packages takes more time than the polling time.

This way the if() would always skip the while loop.

In my modification the lock is at least released for a moment (maybe we should 
put a "yield" into it ?) if this happens.

> > 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"?

yes, select can do this. You just wait for two sockets at once AND set a 
timeout value.

Henning


*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: (spam-protected)
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)