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.

> - when a module crashs, the application will continue - without the
>   functionality of the crashed module

Well - if a module crashes, it is buggy and should be debugged. I don't like
the idea of hiding bugs by some clever workaround. If it is critical, this
can be done without multithreading as well, though it requires a bit more
effort.

> - much less name space problems

If you have a namespace problem, you usually have a design problem with the
namespace rules as well ...

> - 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]> =

Reply via email to