[apaku at gmx.de: Threadsafe access to a KConfig object]

[David Faure]

On Friday 01 June 2007, Andreas Pakulat wrote:
> we (that is the kdevelop developers) face a threading issue. Currently
> the configuration of a Project that is loaded in KDevelop is made
> available via a method that has this signature:
> 
> KSharedConfig::Ptr projectConfiguration() const;
> 
> However as far as we know its not safe to use this method from multiple
> threads. The configuration is not changed in these threads, its just
> read.

Why is it not safe? Assuming that the underlying KConfig is created on startup
and not inside that method, I see no problem with multiple threads using the same
KSharedConfig::Ptr - as long as they use KConfigGroup, not setGroup, of course!

Or does this break somewhere inside KConfig (delayed parsing or caching)?

If it does; a KConfigGroup projectConfigurationGroup(groupname) method might
be a solution because then you can put the mutex inside the method; assuming
that the reading operations themselves are threadsafe.

Hmm, ok, this one is not:
QString KConfigGroup::readPathEntry( const char *pKey, const QString& pDefault ) const
{
  const bool bExpandSave = d->master->isDollarExpansion();
  d->master->setDollarExpansion(true);
  QString aValue = readEntry( pKey, pDefault );
  d->master->setDollarExpansion(bExpandSave);
  return aValue;
}
This is ugly, it should be a method argument instead of a global state...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).