Making Access to project configuration threadsafe
dukju ahn
dukjuahn at gmail.com
Wed May 30 05:51:47 UTC 2007
2007/5/30, Matt Rogers <mattr at kde.org>:
> On Tuesday 29 May 2007 11:54, Andreas Pakulat wrote:
> > Hi,
> >
> > I'd like to ask our thread-experts for some ideas on how we could make
> > accesses to the project configuration threadsafe.
> >
> > Currently the project configuration object can be obtained by
> >
> > virtual KSharedConfig::Ptr projectConfiguration() const = 0;
> >
> > which (afaik) isn't even safe to read from in multiple threads. We need
> > to stick with KConfig* or KSharedKConfig* (or ::Ptr) because there's
> > some logic involved when creating the KConfig object from our two
> > project config files.
> >
> > One way I can see is having a static helper function that creates a
> > KConfig object from two given files which can be called from any thread.
> > The downside here is that plugins get access to either the (possibly
> > remote) project files or temporary copies of them and they can do
> > changes which would be overwritten on project closing. With a
> > KSharedConfig this doesn't happen.
> >
> > Andreas
>
> Is it possible for us to move on to other things instead of dwelling on
> something that already works, although it's a bit slow? Speeding up the
> project parsing is a noble goal to have. However, I think our efforts are
> best focused on making other things work and then go back to make other
> things work better.
I agree that noble goal is making project parsing faster. IMHO, we can
accomplish it
even though we use thread locking, by employing some tricks.
We can use project config caching mechanism. We can have extra method such as
IProjectFileManager::prepareToParse(), and finishedParse(). These method are
called in the parsing thread. What they does is to make and store a deep copy of
project config values, which are used only for that thread. In that
way, frequency of
KConfig locking can be minimized.
But, if it is impossible and parsing speed becomes too slow due to thread,
we should discard thread. Non-blocking GUI is useless if project is not loaded.
More information about the KDevelop-devel
mailing list