On Fre, 2008-02-22 at 13:39 +0100, Erik Tromp wrote:
> Good story :-)

It helps if you write it the 3rd(=?) time;-)

[...]
> > 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 ...).
> 
> This could also happen in the current implementation, if a plugin

ACK. Apparently I didn't point this out enough.
BTW the simple fix for the httpinfo-plugin is to simply
pthread_create(3) or - probably even better - fork(2) as it (almost)
only reads data and after one HTTP request everything can be thrown away
anyways.
But such a simple solution works only for "read-only plugins" which work
on "snapshots" of the data. So it is pretty limited.

> starts a blocking system call inside its scheduler event handling
> function. You'll have to trust your plugin writers to some extent.

ACK. And I see no problem with that as we have to trust them anyways -
now and in the future - as each plugin can do what ever it want with the
internal data structures.

> In other words, if the disadvantage of b) is not worse than the current
> situation, we might accept it.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




