Making Access to project configuration threadsafe

[Kris Wong]

> 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.

>> 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.

Kris Wong