Global QSettings object - thread safety vs. multiple local QSettings objects
from reading the QSettings documentation, I woul assume that sharing a global QSettings object ist not thread safe because multiple thrads could call beginGroup() or endGroup() which would cause a wrong prefix when writing settings. So it seems a better solution is to create local QSettings objects that share the same ini file whenever a functrion or class needs to access these common settings in a single ini file. This is was the documentation states:
QSettings is reentrant. This means that you can use distinct QSettings object in different threads simultaneously. This guarantee stands even when the QSettings objects refer to the same files on disk (or to the same entries in the system registry). If a setting is modified through one QSettings object, the change will immediately be visible in any other QSettings objects that operate on the same location and that live in the same process.
So using local QSettings objects is the way to go and global QSettings objects should be avoided. The only probelm I see, is, that each time such a local object is destroyed, the QSettings::sync() function will get called.
Are these conclusions right or does someone has other experiences or suggestions when using a global settings file to store project settings. Is the sync() call in the QSettings destructor a performance problem if multiple local QSettings objects are used?