Re: Making Access to project configuration threadsafe

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.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> Sounds like a plan, so we'd change from 

> KSharedConfig::Ptr projectConfiguration();

> to

> KConfigGroup projectConfigurationGroup( const
QString& );

If only it were that easy. ;)

In looking at KConfigGroup, it appears to be implicitly
shared.  Not
only is it implicitly shared, but it maintains a pointer to
its master
configuration file, which is where it actually reads and
writes from.
This makes it basically useless for our purposes.  I think
we may end up
having to do something similar to the following:

typedef QMap<QString, QString> KConfigEntryMap;

KConfigEntryMap projectConfigurationGroup( const
QString& );

Although the implementation for this isn't particularly
complex, it
would require us to wonder a bit off the beaten path as far
as the
configuration stuff goes.  If that is not the route we want
to take, we
may want to present the issue on kde-devel.

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 29.05.07 17:36:14, Kris Wong wrote:
> Although the implementation for this isn't particularly
complex, it
> would require us to wonder a bit off the beaten path as
far as the
> configuration stuff goes.  If that is not the route we
want to take, we
> may want to present the issue on kde-devel.

I've sent a mail to kde-devel seeking for help. I do think
we want to
stay in the bounds of KConfig as that eases the retrieval of
values
(think escaping nowadays, getting KUrl's and other types).

Andreas

-- 
Your true value depends entirely on what you are compared
with.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Thursday 31 May 2007 16:32, Andreas Pakulat wrote:
> On 29.05.07 17:36:14, Kris Wong wrote:
> > Although the implementation for this isn't
particularly complex, it
> > would require us to wonder a bit off the beaten
path as far as the
> > configuration stuff goes.  If that is not the
route we want to take, we
> > may want to present the issue on kde-devel.
>
> I've sent a mail to kde-devel seeking for help. I do
think we want to
> stay in the bounds of KConfig as that eases the
retrieval of values
> (think escaping nowadays, getting KUrl's and other
types).
>
> Andreas

suggest forwarding that email to kde-core-devel as well
-- 
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> I've sent a mail to kde-devel seeking for help. I do
think we want
> to stay in the bounds of KConfig as that eases the
retrieval of 
> values (think escaping nowadays, getting KUrl's and
other types).

We would still be in the bounds of KConfig.  Rather than
taking
advantage of KConfigGroup, though, we would directly access
the entry
list for the group (which is what KConfigGroup does anyway).
 There's
also the locking mechanisms David and I had discussed if we
would like
to go that route.

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel