[Olsr-dev] Planned efforts on plugins
Fri Feb 5 15:09:51 CET 2010
On Fri February 5 2010 11:08:10 Teco Boot wrote:
> 3: bmf
> 1.6.2 solved my problem.
> Removing the thread is very low on my priority list, or
> harmful (I have to verify). Same for the 1.5.3 problem.
I think it should be easy to port 1.6 to olsrd without the mutex.
> The problem with 1.6 is the mutex.
> Maybe supply the mutex code on the main olsrd src as patch, and use the
> mutex conditionally?
This would mean you cannot use the plugin without changing the OLSR core (and
> Is it really a bad idea to apply the mutex path?
Yes, I think so. Last time I looked at the mutex patch it just stopped the
whole OLSRd core code until it was ready with its own reading of OLSR data
structures. Thats no real advantage in my opinion.
The problem is that the 0.5.6 scheduler does have a "polling" mechanism. If no
messages arrives, it waits for some time with nanosleep. The scheduler in the
development branch does not have this problem, it can distinguish between
"slow" and "fast" sockets (slow sockets allow to concentrate the cpu time of
An alternative to a scheduler backport would be that the BMF copies the
necessary "nexthop" table for each target, so the BMF-thread does not need to
look up in the central OLSR core structures. This way the waiting time for
both threads could be minimized (just use an atomic switch between two lists
of "next hop for originator" databases in the BMF).
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263, Fax +49 228 9435 685
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the Olsr-dev