Curtis L. Olson writes: > Threading is *really* scarey in a program of this magnitude. Even > the current threaded tile manager is a big time bomb waiting to > happen. We are getting away with doing stuff that's not guaranteed > to work. We've taken a lot of steps to try to minimize the > potential problems, but as the scenery and modeling gets more > complex this problem is only going to get worse.
Threading is relatively safe if each thread is forced to play in a sandbox. A subsystem running in a separate thread must *not* touch any other subsystem (including the property manager), and must send and receive all information through a single, tightly-controlled interface. That implies that a subsystem in a separate thread should not even include other FlightGear header files, much less access FGGlobals, FGInterface, the property manager, or anything else directly. The best candidates for separate threads are processes that have relatively little input or output but require a lot of computation. For example, if some day we have an incredibly sophisticated weather simulator that actually models air currents over different terrain types, we might actually let it do its computations in a low-priority background thread and report back every minute or so. I don't think that threads are a panacea for whatever ails us. Another good candidate for a separate thread would be auto-generated, smoothly-transitioning terrain textures. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
