[Olsr-dev] Planned efforts on plugins

[Joe Gio]

Would publishing the mpr/neighbor data to a common area (shared memory 
possibly) and making bmf a stand alone application be a better approach ?

Joe

On 02/05/2010 09:09 AM, Henning Rogge wrote:
> On Fri February 5 2010 11:08:10 Teco Boot wrote:
>    
>> 3: bmf
>> ======
>> 1.6.2 solved my problem.
>> Removing the thread is very low on my priority list, or
>> harmful (I have to verify). Same for the 1.5.3 problem.
>>      
> I think it should be easy to port 1.6 to olsrd without the mutex.
>
>    
>> The problem with 1.6 is the mutex.
>>      
> Yes.
>
>    
>> Maybe supply the mutex code on the main olsrd src as patch, and use the
>> mutex conditionally?
>>      
> This would mean you cannot use the plugin without changing the OLSR core (and
> recompile it).
>
>    
>> Is it really a bad idea to apply the mutex path?
>>      
> Yes, I think so. Last time I looked at the mutex patch it just stopped the
> whole OLSRd core code until it was ready with its own reading of OLSR data
> structures. Thats no real advantage in my opinion.
>
> The problem is that the 0.5.6 scheduler does have a "polling" mechanism. If no
> messages arrives, it waits for some time with nanosleep. The scheduler in the
> development branch does not have this problem, it can distinguish between
> "slow" and "fast" sockets (slow sockets allow to concentrate the cpu time of
> multiple events).
> 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
>
>