[Olsr-dev] First release of IP Autoconfig daemon (PAA)

[Bernd Petrovitsch]

On Fre, 2007-11-30 at 09:11 +0100, Roar Bjørgum Rotvik wrote:
[...]
> I'm not sure that moving the PAA daemon into olsr would bee a good idea.
> Some issues:
[...]
> * If olsr is still single-threaded it could hurt routing performance to implement even 
> more processing in the single-thread event loop in olsr.

Given a somewhat good implementation (read: state-machine(s) everywhere
with non-blocking syscalls), this is not really the case: even if you
have only 2 threads competing for the CPU, they won't need less time to
complete (and maybe even more since permanent cache flushing on context
switches is not that cheap - neither on high-end CoreDuo2 nor on the
low-end ARM/MIPS/PPC/....).
Even worse multi-threaded processes imply - sooner or later[0] - that
one needs explicit locking. First this additionally costs performance
(even if they never really block) and deadlocks must be avoided
(according to chp. 3 of http://www.cs.vu.nl/~ast/books/mos2/, olsrd uses
now the "Ostrich algorithm" to handle them).

IMHO the olsrd is not single-threaded (and wasn't at 0.4.* times) since
there were plugins there which created threads and interact with the
core.
Even if these plugins are now read-only (and some aren't - otherwise one
could think to use fork() and use read-only shared memory) it would be
IMHO just a question of time until the first comes along and starts to
write into the various data structures (e.g. httpinfo+admin-interface,
it may make sense for a SNMP plugin, ...).

BTW I see no easy short-term solution of the above.

	Bernd

[0]: For those who do not follow the Asterisk(TM) implementation (yes,
that famous Soft-PABX): They start *now* to add locking there. Asterisk
was multi-threaded since the start AFAIK. And yes, there were real
problems which usually occured if there was some load on Asterisk (read:
after deployment when people simply use it) and than the race conditions
start to become bugs. And this is usually not fixable in the short time,
you can just work-around (read: rewrite the dialplan to not use the
dangerous operations) .....
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services