[Olsr-dev] Planned efforts on plugins
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
> > 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Olsr-dev