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

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

Advantages:
        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
will).

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.

[clip]
> > - 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