[olsr-dev] Re: olsr bmf question

Erik Tromp (spam-protected)
Tue Jan 2 17:42:22 CET 2007

If you have a solution, I would very much like to use it too!

As I said before, BMF (like any plugin with its own thread)
also has this potential race condition, which may happen when
the plugin thread reads from OLSR's data
while the OLSR thread is writing to that same data.

As for the call to select() with a specified non-zero timeout as
the last parameter: I had the experience that it causes a high
(100%) CPU load. This behaviour was observed under a Debian
installation using Linux kernel 2.6.8. I didn't have the time to check
if this was caused by a bug or misconfiguration, but we may need
to watch this carefully.

Best Regards,

----- Original Message ----- 
From: "Ignacio García Pérez" <(spam-protected)>
To: "OLSR development" <(spam-protected)>
Sent: Tuesday, January 02, 2007 4:50 PM
Subject: Re: [olsr-dev] Re: olsr bmf question

I sort of need it for an experimental plugin I'm developing. As happens
with the BMF plugin, I need immediate handling of incoming packets, but
do not want to use a sepparate thread because that introduces race
conditions that compromise the stability of the whole olsrd process.

I'll give it a quick shot and see how hard would it be to refactor the
code this way. As I have to study the olsrd code, any indications on
where to look and what to change will be greatly appreciated.


More information about the Olsr-dev mailing list