[Olsr-dev] Planned efforts on plugins

Henning Rogge (spam-protected)
Sun Feb 7 18:58:07 CET 2010

Am Sonntag 07 Februar 2010 18:38:41 schrieb Erik Tromp:
> > I know, but the mutex is no sollution at this place.
> Well... in fact it is a solution. Maybe you don't like it, but that is
> another issue.
It's no sollution because it does not allow for multithreading. Either the 
OLSR core can do some work or the BMF. That's no advantage beyond a 
singlethreaded programm.

> > We are thinking about copying the scheduler from the master branch.
> Keep in mind, though, that moving towards a single-threaded solution does
> not eliminate the possibility of the OLSR main process getting blocked by
> one of the plug-ins. The registered plug-in function may, after being
> called, never return (or return only after a very long time).
This can happen too with the pthread+mutex sollution. If the BMF would not 
return from it's mutexed loop the OLSR-Core would stop.

A plugin which does not return within a SHORT amount of time would be buggy in 
my oppinion. If there is a job that needs lots's of computational time, maybe 
it should be not an OLSRd plugin. Just put it in an application of it's own 
and read the necessary data through a plugin with a socket.

> In fact, switching from a multi-thread solution towards a single-threaded
> solution is to some extent the same as exchanging the OS-scheduler for the
> OLSR-scheduler.
And getting rid of synchronization problems.
> Windows 3.1 used so-called co-operative multitasking. There was only one
> thread, issued by the OS. Applications registered with the OS their
> functions to be called. Those functions had to return quickly otherwise the
> OS would hang. We've come a long way since then.
Yes, but it's still a good sollution in a server application working on a 
single set of data. The databases inside the olsrd core are not designed for 
concurrent access.

Henning Rogge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100207/c009d34e/attachment.sig>

More information about the Olsr-dev mailing list