[Olsr-dev] Planned efforts on plugins
Sun Feb 7 13:59:11 CET 2010
> 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).
> Henning Rogge
That is not such a good idea. Making a copy of a table needs, of course, to
be done in a thread-safe manner. And that would require.... again a mutex.
Having the OLSR-thread to do the copying is no advantage, because then again
the BMF-thread must be blocked from reading while the OLSR-thread is writing
into the copy of the table (and vice versa: the OLSR-thread must be blocked
from writing while the BMF-thread is reading).
Whenever there are multiple threads, there will be mutexes. Getting rid of
the mutex require we use a single-threaded model. This would be possible if
plug-ins (like BMF) can register for socket events. Preferrable in a
non-polling way, otherwise the performance is severely degraded.
See also our mail conversation around 29-7-2008:
> > 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
> 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"?
More information about the Olsr-dev