On Mon, 24 Jan 2000, Andreas Beck wrote:

> A few thoughts about multithreading LibGGi3d:
> > 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
> And worse on non-SMP, or if the number of processes exceeds the number of
> CPUs. Note, that you will often have to switch between modules very rapidly
> to avoid having large queues that will introduce large latencies, which is
> quite as bad as slow rendering for 3D stuff. Thus scheduling overhead will
> get pretty large.
> So IMHO one should rather _avoid_ multithreading, except for _large_
> independent tasks. The natural way to do this is in the user program, like
> separating input, scene calculation and rendering.

You speak about the way, which is done in degas/lib/libggidemos/subdemo ?

> > - much less name space problems
> If you have a namespace problem, you usually have a design problem with the
> namespace rules as well ...

Yes, you're right. But what I want to say is: Writing some code shouldn't
brake any other code.

> > - Debugging can be done much better
> You are not serious, are you ? Ever tried to debug a multithreaded
> application ?


> It's a nightmare.


> > - LibGGI3D can be much easier ported to other platforms
> They would have to support multithreading or fork()ing and shmem.
> For example on windows, fork() is a very very expensive thing.
> Compile LibGGI there and see the makefiles at work ... :-(
> And multithreading isn't supported too well on many OSes.
> Not _requiring_ these functions would be beneficial IMHO.
> I'd say go like LibGGI: Support threads if available, but don't require
> them.
> > - modules can be developed and tested indepently from the developing of
> >   LibGGI3D itself.
> That's the idea behind any module concept. It shouldn't make a difference
> how it is implemented. A minimal wrapper application should be easy to
> build.
> CU, ANdy
> -- 
> = Andreas Beck                    |  Email :  <[EMAIL PROTECTED]> =

Christoph Egger

Reply via email to