Hi Kristian, working with the Config can be challenging at times... On 17.01.25 17:44, Kristian Amlie wrote:
Hmm, yes, the split between instance data and state data is rather murky waters.
I can just agree to that. But right now we somehow have to live with it, because separating both would be a quite deep refactoring of the whole engine. Thus, for me it was always helpful, to sort those categories apart, at least mentally. The changed / new logic applies to base/instance config. There are other fields in the Config object, which are treated differently. With the new handling/policy present since last release, config is no longer saved explicitly by the user having to activate on some "save" functionality. Rather, it happens immediately and automatic. This has one important ramification: We now have some kind of *Invariant* in place: I'd like to formulate it the following way: "Config in memory *must not differ* from Config on disk" That means, whenever some piece of logic changes a setting that is considered *Config* (as opposed to runtime state), than that very piece of logic is responsible for making that change persistent. Otherwise we'd break this new contract, and get into quite confusing states. On 17.01.25 09:13, Kristian Amlie wrote:
2. Standalone instance(s) with state saving and loading. * Starts out like scenario 1. * When saving a state, saves everything currently in the config. * When loading a state, all configuration settings (in memory, not on disk) are overwritten by the ones in the state. * When saving the state again, the settings from the loaded state are saved. * When changing a setting, that specific setting is saved to the instance config. The rest of the settings (which are different from the ones in the loaded state) are left alone.
Thus I'd approach this scenario as such: I'd try to spot any place where the Config in memory moves away from the Config on disk. Because, if both are always kept in sync, it does not matter to what degree we actually load / write back to disk. As long as we're able to persist any change in memory which is relevant. This was basically the trick which I applied when investigating the problems with the XML compression (which was a long standing issue). And indeed, I found a path where a setting from another instance config could leak into the state (this is fixed now). Thus, I'd look at that point you mentioned here
* When loading a state, all configuration settings (in memory, not on disk) are overwritten by the ones in the state.
Applying the "Invariant" from above, both /should not/ be different. And thus it would not matter reading back config settings from disk. Thus I'd propose to ask, why is there a setting in memory which was not (yet) persisted? Can it be persisted immediately close to the point where it is changed? Or is there something in the Config object, which is not considered "config" proper, but also overwritten when loading (because that would be a bug then)? -- Hermann PS: I do not want to come over as "nitpicking", rather trying to be helpful, because I had also quite difficult times with getting Config correct... _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
