[okay, any ideas for -profiling- my multithreaded nightmare? :]
[now supports MPEG-2 and MPEG-1 video.  Uploaded to geocities account in a
few minutes here - or when I finally get the help-screen to stop
blinking *sigh* :]

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.

Agreed with one kudo:
Running a seperate 3D-server is a good way to go.  But not multithreaded.
Definitely not multithreaded.

        Yes it slows your system down.  It's also hard to communicate with.
        words Security Nightmare also come to mind...

        Won't kill your hardware if your main program crashes.
        Isn't hurt by input or other processing/signals/...

I don't know what else.
incidentally, there's not much point to a seperate proggy if you're
blessed with a 3D-card with an infinite uploadable pipeline - or one
that's faster than your program anyways :)

> > - 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.

Graphics libs + modules -must- be bug-free.  X is a beautiful example of
why.  (one way or another).
Agreed here too.  But a good debugger is -hard- to find.

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

If you have a namespace problem you haven't thought things out for sure.
-> GGI doesn't really have a namespace problem with all it's modules
loaded....  *grin*

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

It's worse than that...  Especially if graphical.
Thanks to the 'aa' target I can debug that quicktime player monstrosity at
all.  It only uses... um... 5 threads at the moment (render:sound,
render:video, decompress/pipeline, messaging, and a main program
messageloop.  Now I -could- have nixed that last thread.  AMAF I think I

Oh, and one last point.  Communications between threads or processes is
evil.  Really evil.  Case in point : locking of shared data within the
linux kernel.  I've had more communications bugs than I can throw a stick
at.  It's definitely a debugging nightmare.

> > - 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.

Providing you know how you want it to work.  Ref: that scaling target I
keep meaning to write....  Okay.   It translates coordinates.  It works
really nicely copying buffers.  Any suggestions? :)

G'day, eh? :)
        - Teunis

Reply via email to