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 ?
No...
> It's a nightmare.
Ooops...
>
> > - 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
E-Mail: [EMAIL PROTECTED]
