Anders Gidenstam wrote: > On Tue, 7 Apr 2009, Anders Gidenstam wrote: > >> Can we find a better/more general solution to that problem (i.e. setting >> the value of a subtree or a set of properties), >> because someone might need to set a 3 doubles in one go at some point, or >> 7 doubles or why not 3 doubles and a string? > > Some additional thoughts on atomicity: we have several levels of "setting > a bunch of values in one go" in FlightGear: > > 0. All subsystems can (potentially) see inconsistent state while the > update is in progress. E.g. setting a set of properties from the telnet > interface (IIRC the commands will be processed on at the time with > potentially several frames occuring between them). > > 1. Only listeners/getters/setters triggered by the updates can see > inconsistent state. This is (AFAIK) the case when setting several > properties from a piece of Nasal code. Other subsystems can't see the > intermediate states since we (AFAIK) don't interrupt Nasal code. > > 2. Atomically updating of a set of properties. AFAIK we don't have that > today. > We should also think about atomicity in terms of multithreading and what it would take to guarantee that different threads see a consistent view of the property system. I realize that could be (unsatisfactorily) solved by a lock, whereas insuring that listeners get fired after a consistent set of changes is a slightly different problem.
Perhaps we should take another look at the "brittle hack" :) I'd be willing to explore that approach if it could be guaranteed that child properties could only be written in a context where only one listener event would be fired on the parent. Tim ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
