Andy Ross wrote:
Martin Spott wrote:
I suspect the network stuff is coupled to the same loop as is the
screen display. Just a guess, though ....
It is. Everything except for terrain tile I/O is driven out of the
main loop. Probably something that should be fixed...
Note that we're going to have to start thinking about threading
designs soon anyway, if we want to take advantage of all the fancy
multi-core/multi-thread CPUs coming down the pipe. Rendering
obviously has to stay within a single thread, but how much
non-rendering work can we push out to worker threads? Ideally,
everything would be "handed" to the renderer thread each frame, with
all the matrices pre-cooked and ready for OpenGL calls.
I would like to make a case for non-threading from the standpoint of
simplicity. We have had (and probably still have) some extremely subtle
and extremely difficult to track bugs in our threaded tile loader.
We've been forced to use threading for our tile loader simply because of
performance reasons. We can't afford a big stutter in our animation
when ever we need to load new tiles.
When a single person is writing a smaller threaded app, things can work
out quite well because one person (who understands all the underlying
issues) can think through the code very carefully and ensure that all
possible timing, locking, and communication related events are handled
robustly.
But now project that onto a project like FlightGear. Even if one highly
skilled person set us up with lots of threading that worked perfectly,
given all the contributions from a variety of sources (many of which I
know have no clue about threading issues) how long do you think it will
be before everything is hopelessly fouled up? Some simple "naive"
change to fix some bug or add a new feature could inadvertantly
introduce a subtle threading bug that only happens very rarely, but is
still unacceptable.
Personally, I think that the idea of threading in the context of
FlightGear is a *very* scary idea, especially from the standpoint of
long term maintanence and keeping our code robust. I'd perhaps favor
splitting our code out into separate applications that use networking or
shared memory or pipes to communicate. You lose some of the context
switching efficiency of threads, but I think the code becomes more
robust and maintanable because changes have less of a chance to
propagate elsewhere to unintended areas ...
Just my 2 cents ... :-)
Curt.
--
Curtis Olson http://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
