Lawrence Manning writes: > Well, with threads you can spread the load across CPUs. So it is not just > a convience for the programmer. Afterall, the original poster bought up > the matter of big boxes with lots of slow processors.
Right, but we should also bear in mind the a) "typical" flightgear platform, b) the fact that the bulk of the flightgear application work is in rendering the 3d display, c) the practical problems that things like opengl and our property system is not thread safe, d) the complexity and subtle bugs that threading *very* often introduces when added to large complex applications. I don't want to add a bunch of threads if the only reason is that threads looked cool and fun when we studied them in a computer science class, and there is one person with a machine that could benefit. If someone does want to go thread crazy, please do it in a fork of the source code. I'd be interested in hearing the results and any issues or problems that were encountered as well as any performance gains realized. > The only way to utilise those is with multiple threads and/or > processes. But I'm definetly not suggesting that fg would gain alot > through threads, because the biggest job (rendering) is not > suitable. Did anyone say if this multi-cpu machine had an accelerated opengl graphics system? If it doesn't then this whole discussion is pointless. :-) > LOL, okay. Stumped :) Hey how about no display at all... You can almost do that ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
