#266 Settings: serialize saving between IDEs of the same Delphi version, or save changes immediately

[Thomas Mueller]

Background

All IDEs of one Delphi version share one GExperts settings key in the registry, including the 32 and 64 bit RAD Studio 13 IDEs. When two of them save at the same time, for instance when both are closed together, their writes interleave.

Bug #519 was the worst consequence: a string list was saved by deleting its key and writing it again, so one IDE could delete the key while the other was writing into it ("Failed to set data for 'Count'"), and a list was gone as soon as any write after the delete failed. Since revision 5843 the key is never deleted, so this can no longer fail or lose a list. What remains is that two IDEs saving at the same moment can still leave a mix of both: for each value the last writer wins, and one list can end up with its count from one IDE and some of its items from the other.

This request is about removing that remaining mix. Two approaches are described below.

Option A: a cross-process lock, and no writing without it

A named mutex, derived from the settings key, taken around every save, including the whole save at shutdown, so that one IDE saves completely before another starts. A version of this that waited at most 5 seconds and then wrote anyway was implemented and tested (two IDEs closing together saved one after the other), but not committed: a lock that is ignored after a timeout is not a real lock. The requested behaviour is that a failed lock prevents writing. That requires:

1. Skipping without exceptions. An exception from the write path would escape from the experts' destructors at shutdown, where each expert saves its settings, show "GExperts error destroying expert ..." for every one of them and cut their clean-up short. Instead, a settings object that could not get the lock has to turn all of its writes into no-ops.
2. All or nothing at shutdown. If the lock around the whole shutdown save cannot be acquired, none of the roughly 100 individual saves inside it may write either. Otherwise each would try again, and some might get the lock once the other IDE is done, leaving half of the settings saved. This needs a process-wide "saving disabled" state that every later save checks.
3. Telling the user. Skipped saves lose what was changed: at shutdown everything of that session (Grep history, window sizes, configuration changes). A message is needed, at least for the configuration dialog and the configuration import, where the user expects the change to stick, and probably also at shutdown, even though that is a blocking dialog while the IDE closes.
4. The first-run migration of the settings of an older GExperts version can simply be skipped; it is attempted again on the next start.
5. A longer timeout. A normal save takes a fraction of a second, so a timeout only runs out when the other IDE hangs while holding the lock. Since skipping is now the expensive outcome, the timeout should be longer, around 10 to 15 seconds. As long as the hung IDE holds the lock, every other IDE loses its saves. A lock left behind by a crashed IDE is not a problem: Windows reports it as abandoned and hands it to the next waiter at once.
6. Every writer has to take the lock. Besides the settings classes in GX_ConfigurationInfo.pas, the configuration import and the settings migration write the key directly through TRegistry. An older GExperts DLL of the same version that does not know the lock would still write unsynchronized.

Most of it is in GX_ConfigurationInfo.pas (lock class, no-op writes, the process-wide state, a message helper), plus TGExperts.Destroy, the configuration dialog and the import.

Option B: save changes immediately, read settings when needed

Instead of keeping settings in memory and saving them when the IDE closes, every change could be written to the registry when it is made, and settings could be read from the registry whenever they are needed rather than once at start-up. Two IDEs would then rarely save the same thing at the same moment, and a change made in one IDE would show up in the other.

This can only go so far. Some state has to stay per IDE instance: enabling or disabling an expert, for example, must not switch it on or off in another running IDE, and making that expert state follow the registry live would be difficult anyway. It also touches every expert, since each has its own load and save code, and some settings (window sizes and positions, histories) change so often that writing them on every change is not attractive.

Related

Bug #519 (fixed in revision 5843).