Hi Melchior, On Sunday 01 July 2007 15:47, Melchior FRANZ wrote: > I appreciate your work on the Traffic Manager, but ... > > * Durk Talsma -- Sunday 01 July 2007: > > The message is related to a routing problem in the AI system, > > which actually causes a controlled exit from FlightGear. > > Please remove the "controlled exit". There's no reason why a > user flying along should get punished with a "controlled exit", > because the Traffic Manager has a routing problem. Make the > manager heal itself (recover gracefully) or make it commit > suicide. But taking down all of fgfs is IMHO unacceptable > and rather poor coding style. It makes all of fgfs look bad, > when just one part of it is. And I doubt users will be > grateful ... "OMG, a routing problem in the traffic manager! > Thankfully, FlightGear didn't let me continue my transatlantic > flight under these circumstances, even though I was on approach > in KJFK already." :-} >
I will look into that. FWIW, most of the exit()' s in the code were placed there during the early stages of development, and anyone of those remaining is in a spot where the probability of an error has become extremely small Or just nobody is reporting all those frequent AI subsystem crashes. I agree that it can be very frustrating to have a flightgear session cancelled due to an exit, and in a released version, this should be avoided. However, the flip side is that if we continue to "gracefully recover", its going to be a lot tougher to weed out the /root/ cause of any bug. For instance, there is a good chance that the underlying error in the KSAN groundnetwork would not yet have been fixed already if FlightGear hadn't exited on detecting the error. In my opinion, letting errors accumulate is not compatible with the "doing things right" mentality of FlightGear. My proposal is to do the following: Have a new boolean property, which could be specific to the AI system, but potentially attributable to the whole sim. This property called something like /sim/permissive-error, could determine how FlightGear responds to a potential error condition in a subsystem. If set to "true" it gracefully recovers, or shuts down the subsystem. If set to "false", it pedandically exits FlightGear. FWIW, I believe the default setting of this property should be "true" in CVS, but turned to "false" the moment we enter the feature freeze period just prior to release. The reason for this being simple. Whenever we are working on packing up a release the priority should be to work on a system that is as stable as possible as a whole. However, people running CVS code know they are playing with the bleeding edge version, and part of the process is to try and weed out any remaining issues as thoroughly as possible. The only way possible is being pedantic. Thoughts, ideas, objections? Cheers, Durk ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
