On Wed, 2008-07-30 at 07:50 +0200, Henning Rogge wrote:
[...]
> At the moment Olsrd has no support for multithreading. Instead of locking the 

Because the "core" doesn't really needs it - only 2 plugins IIRC.

> mainloop from a (or multiple) plugin(s) I suggest we enhance the  
> add_olsr_socket() function with an additional parameter called "realtime":

Can we rename it to "soon" or "immediate" something similar.
"Realtime" already has a defined semantics in computer science - and it
is not "as fast as possible" or anything near that (though lots of
clueless people - mainly from sales departments et al.;-) - use it with
that false meaning).
The true meaning has to do with "meeting guaranteed deadlines in time in
100% of all cases" - which is not the case or intention here AFAIU.

[....]
> I think this sollution will be as flexible as a locking mechanism without 
> needing support for multithreading at all.

As long as the called functions of this "immediate" sockets *do* *not*
*block* in anyway possible for any reason.
Read: the I/O (and all other operations) there *must* be *non-blocking*.
Basically one should use e.g. only non-blocking file descriptors there
(which rules FILE * out - or is there a non-blocking interface for FILE
*?[0]) and handle -1 graceful.
Otherwise we would allow at most one immediate socket. Or one has subtle
problems which occur seldom and are not reproducible.

	Bernd

[0]: My non-blocking experiences are from raw file descriptors (and not
         the bloated FILE *;-).
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




