[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
