On 2000/Jan/25, teunis wrote:

> Running a seperate 3D-server is a good way to go.  But not multithreaded.
> Advantages:
>       Won't kill your hardware if your main program crashes.

        This is one of the reasons why the 3D hardware support must be into
the kernel (of course, the main one is that "it's hardware, you shouldn't
talk directly to the hw on a unix machine!!").

>       Isn't hurt by input or other processing/signals/...

        My opinion is that it's more usefull, interesting and important to
have the stuff that you want to put on this server, into the kernel, at
least partially, and If i'm right it's what is being done with KGI... It
doesn't crashes the hardware, it doesn't have security problems, it can
avoid easily multiple tasks accessing to the hardware, and assign the
display to the focused one (the one that is on the current console), etc.
        How can you control from this server which task should show it's
graphics and which one you should ignore commands from?
        From the kernel, instead, it's very easy...

        My opinion is this, let the kernel do it's work (avoid tasks
problems, security problems, hardware abstraction, etc.) and use servers for
the things that they should be used (of course, neither hardware
abstraction, nor tasks controlling, I hate X-Window system design, most of
it should be at the kernel).

> Graphics libs + modules -must- be bug-free.  X is a beautiful example of
> why.  (one way or another).

        X is beautiful? You mean XGGI, do you? :)

> Agreed here too.  But a good debugger is -hard- to find.

        gdb and electric-fence are your friends (at least are mine ;)

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

        Well, if you have only one monitor and video card that's true, but,
for example, if have the luck of have your computer connected to another
one, you can launch the gdb remotely and launch the graphics on the local
video card.

> Oh, and one last point.  Communications between threads or processes is
> evil.  Really evil.  Case in point : locking of shared data within the

        I think that you should abstract the communications as much as you
can, and centralize them as much as you can also, this should reduce the
bugs to the minimum, and should make it easier to localize them. It can
reduce the speed a lot, but I think that the first step is to make it
running with quite beautiful code, and when running, optimize to the
maximun. The inverse way always makes you lose a lot of time.
 /_) \/ / /  email: mailto:[EMAIL PROTECTED]
/ \  / (_/   www  : http://programacion.mundivia.es/ryu
[ GGL developer ] & [ IRCore developer ] & [ GPUL member ]

Reply via email to