Making Access to project configuration threadsafe

[Andreas Pakulat]

On 29.05.07 15:18:17, Kris Wong wrote:
> > I'm not sure that reading really is a non-issue, keep in mind that
> > we're dealing with implicitly shared kconfig objects here. At least
> > thats the impression that I got from the answers on kde-devel.
> 
> Let me rephrase, reading is only an issue when the possibility exists
> for a simultaneous write.  i.e., multiple simultaneous reads w/o the
> possibility of a write would not require any sort of locking.  In the
> scenario, the possibility of a write exists, so reading is an issue.

Ok, thanks for clarifying (to myself) that I do actually have a basic
understanding of when locking is needed (and what type) :)

> >> 1. The project only gives out and accepts deep copies of the
> >> configuration.  It will have one mutex which will be locked for long
> >> enough to deep copy into another configuration object (in the case of
> a
> >> read), or from another configuration object (in the case of a write).
> >> The down side to this is obvious, it is inefficient.  The upside are
> >> that it is a simple implementation and not prone to errors. Depending
> on
> >> the size of the configuration object and the amount of accesses, it
> may
> >> be sufficient.
> 
> > As the KSharedConfig pointer is supposed to be short-lived and
> > Kconfig is meant to be accessed often (pretty fast in KDevelop3) I
> > think this could suffice.
> 
> Actually, I think a good solution would not be to deep copy the entire
> config object, but rather 1 particular group.  Since each particular
> piece of code is usually only going to be concerned with the options in
> one particular group, the config could be locked in order to deep just
> that group.  This would save a lot of overhead in not copying a bunch of
> stuff that we're not concerned about ATM.

Sounds like a plan, so we'd change from 

KSharedConfig::Ptr projectConfiguration();

to

KConfigGroup projectConfigurationGroup( const QString& );

Fine for me.

Andreas

-- 
Your love life will be... interesting.