Christoph Egger wrote:
> > Not yet. The best existing examples are the 'zbuffer' and 'debug'
> > modules. I'll try to get a real skel.c written soon.
> But IHMO the way of implementation the module concept is bad. I think the
> modules should be self-running programms and they use shared memory for
> communication. This will have this advantages:
> - better scaling on SMP-machines
well, wrt to scaling I think the best thing you can possibly do is to use a
producer/consumer architecture in conjunction with a thread pool. The idea is
that if you only have one CPU, you probably don't want much context switching
(which would be necessary for either multiple processes or threads) so the one
thread could simply process the tasks as they show up on the various task queues.
In a nutshell, using a thread pool makes scaling simple: use as many threads as
you have CPUs.
> - when a module crashs, the application will continue - without the
> functionality of the crashed module
How *can* the application continue running without reconfiguring the pipeline
to bypass the misfunctional module ?
> - much less name space problems
> - Debugging can be done much better
> - LibGGI3D can be much easier ported to other platforms
> - modules can be developed and tested indepently from the developing of
> LibGGI3D itself.
All true. With my proposed task / thread pool approach you can test individual
tasks. If you have some acceptor which's responsability is to take the task out
of the task queue and feed it into the module's input stream, you may just for
testing drop the threading stuff and just feed whatever data you want as the input.
debugging then means simply to compare the output stream to whatever you expect to
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
...ich hab' noch einen Koffer in Berlin...