On Fre, 2008-02-22 at 09:54 +0100, Erik Tromp wrote:
> We had this discussion before (december 2006).

I also find Novemebr 2007
http://lists.olsr.org/pipermail/olsr-dev/2007-January/000776.html and
http://lists.olsr.org/pipermail/olsr-dev/2007-November/001485.html
in the archives.

> Using a polling mechanism to read the packets to be forwarded would
> seriously impact the forwarding performance. Unless the polling

ACK. Unless I misunderstood something, polling is not necessary.

> is done 1000 times/second, but that would monopolize the CPU.

If one uses "polling" ....

> > > I agree, OLSR should provide a way to plugins for them to 
> > > thread-safely access (or at least read) the OLSR data.
> > The other way would be easier.
> > Plugins should be able to register their sockets in Olsrd so 
> > they can be polled by the olsrd mainloop.
> > 
> > No need for two threads.

ACK. I see 2 possibilities (see also the "January" link above):
a) add locking to the core+plugins by means of appropriate API functions
   (or more realistically some wrappers since at least Windows
   needs something different than POSIX-threads), or
b) (as Henning proposes IMHO) plugins can also register file descriptors
   in the main event loop and are called when something is readable
   and/or writable there.

Advantages of a):
- IMHO easier to implement for people (as it avoids explicit state
  machines)
Disadvantages of a):
- Deadlocks must be avoided. How?
  Yes, I know Tanenbaum's chapter about that in "Modern Operating
  Systems 2". I meant more: How to avoid it here and in practise and in
  the future minimizing potential errors and human auditing.
- We have locking in the core even if the threaded plugins are not
  loaded and the core as such can live without it. Yes, one could reduce
  that with function pointers which are changed if a threaded plugin is
  loaded.

Advantages of b):
- Deadlocks are much harder to implement.
- No loss of performance etc. due to the explicit locking.
Disadvantages of b):
- After initial initialization and configfile handling, *every*
  potentially blocking system-call *must* go through the main event loop
  - otherwise some subsystem or plugin may block the whole daemon (like
  e.g. the httpinfo ATM if the client reads very slow ...).
  In my experience[0] this boils down that you have on each "read" and
  "write" side buffering implemented which handles the (potentially
  incomplete) reading and writing of data and call some function to
  handle e.g a completely received OLSR packet. And the handler simply
  doesn't block - because he is not allowed to - (no read(2) or write(2)
  syscall, no DNS request with gethostbyname(3), etc.)
  If such a call is inevitably necessary, you break it there and start
  to create a state machine with all it's pros and cons (and invest some
  thinking since the calls to the backend are not synchronized).

Both have IMHO the disadvantage that it is a some work (and not a hack
for a free and rainy weekend) and it will IMHO touch almost all parts in
one way or the other.

<borrowing a maintainer hat for a moment>
As long as no one looks into either solution and implements something, I
wouldn't force a decision.
</borrowing a maintainer hat for a moment>

And no, I can't any "compromise solution".
Except perhaps the current state (aka "Ostrich algorithm"): Don't use
threads in the core and force plugins to live with it.
OK, we could forbid plugins to pthread_create(3) but tell them to
fork(2). But that also needs additional infrastructure and code to get
information from the core into the plugin (via pipe(2), shared
memory/semaphores, etc.).


	Bernd

[0]: I used that pattern of implementation for other daemons. Much
     smaller (and thus probably simpler) ones than "olsrd". For the
     "olsrd", I didn't even start to think/plan in that direction -
     mainly because is more room left for simplification of the current
     code base.
     You can read this as "if I have to choose, b) is the way better way
     to go if I'm alone". But it makes absolutely no sense if everyone
     else stops supplying patches because it feels to
     complicated/unknown/strange to them.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




