[olsr-dev] Re: olsr bmf question

[Bernd Petrovitsch]

On Thu, 2006-12-21 at 09:35 +0100, Ignacio García Pérez wrote:
[....]
> IMHO, the locking problem must be addressed somehow and soon, because I 
> think it hampers the development of olsr plugins, which seems to be one 
> of its bests strenghts. As we have discusses before, there are two ways 
> to do this:
> 
> 1- Multi thread, and provide appropriate locking mechanisms.
... and an appropriate "locking strategy" beforehand.

> 2- Single thread (as it is now), but rewrite the scheduler main loop in 
> the above described way.

It then goes down the road to use something like http://liboop.org/ to
manage file descriptors and timeouts.
Basically you register call-back functions for the various events and
they are called by the library.

> The current single thread scheme is nice, because one does not have to 
> deal with the usual locking headaches (deadlocks and such). However, 

ACK.

> IMHO it has a serious limitation: gives too much power to plugins. As it 
> is actually sort of cooperative multitasking, any DOS attack to a plugin 
> will bring the whole olsr daemon (and network) to its knees.

Yes, the "liboop approach" implies (more or less directly) that there is
no sleep(3) or similar blocking function. And blocking I/O in general is
bad in that approach.
It works quite well for relatively simple daemons (and thus protocols)
which do almost only:
- get some packet asynchronously
- handle it completely immediately (for whatever that means).
Every sleeping/blocking/waiting must be done via some callback function
(or a the whole daemon is blocked ....). And this includes "sending a
packet" (since these functions also can sleep).

> Any thoughs? (specially interested in yours, Andreas).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services