[Olsr-dev] Planned efforts on plugins

[Erik]

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

Best regards,
Erik