Thread-safety issue in cmake support ?

[Andreas Pakulat]

On 09.06.10 01:01:18, Aleix Pol wrote:
> On Mon, Jun 7, 2010 at 9:28 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> 
> > On 07.06.10 19:52:01, Aleix Pol wrote:
> > > On Mon, Jun 7, 2010 at 7:40 PM, Milian Wolff <mail at milianw.de> wrote:
> > >
> > > > Christoph Cullmann, 07.06.2010:
> > > > > On Monday 07 June 2010 18:57:27 Milian Wolff wrote:
> > > > > > Christoph Cullmann, 07.06.2010:
> > > > > > > On Monday 07 June 2010 18:34:42 Andreas Pakulat wrote:
> > > > > > > > > Error occurs either in main thread or in plugin. When in main
> > > > > > > > > thread it raises from
> > > > > > > > > a slot execution which it turns call a method using
> > > > introspection,
> > > > > > > > > making things difficult to investigate.
> > > > > > > > >
> > > > > > > > > IMHO, a lock in CMakeUtils would be a possible solution.
> > > > > > > >
> > > > > > > > Oh, or we could just drop KConfig usage and use QSettings for
> > the
> > > > > > > > project files. After all we might have to get rid of kcm-usage
> > for
> > > > > > > > project-config too. The only thing we'd loose is the ability to
> > > > read
> > > > > > > > from two files "at the same time". But then again, maybe its
> > even
> > > > > > > > good that where stuff is written is more explicit so we can
> > more
> > > > > > > > easily move things around...
> > > > > > >
> > > > > > > QSettings ist not thread-safe, only reentrant.
> > > > > >
> > > > > > Making the foreground lock look even better :)
> > > > >
> > > > > I can only second then Andreas, you will kill your multi-threading
> > then
> > > > > completly I guess :/
> > > > >
> > > > > Like the name, the BKL (either big kernel or big kdevelop lock), you
> > will
> > > > > get lock contention really fast I guess, didn't you already some
> > > > profiling
> > > > > work, showing that atm the lock contention is high?
> > > > >
> > > > > I don't know any solution for the locking problems beside the bkl,
> > too,
> > > > as
> > > > > kdevelop just intermixes to much stuff without locking and with the
> > gui,
> > > > > but keep in mind: each event, each mouse move, anything will trigger
> > the
> > > > > locking of this lock and compete with all your background threads,
> > which
> > > > > compete with each other then, too.
> > > >
> > > > True, it's a sad world we live in :)
> > > >
> > > > If someone has a better idea, I'm all for it though :-) Until then,
> > it's
> > > > probably the only thing we can do.
> > > >
> > > > There are sadly too many tools out there which we must use that do not
> > work
> > > > in
> > > > a multi threaded environment...
> > >
> > > why can't we just serialize KConfig accesses inside CMake plugin?
> >
> > Because its not the only one accessing kconfig. The problem actually
> > happens mostly when one thread accesses the project config while the
> > cmake plugin tries to do that too. So the only way to fix that is having
> > 1 global mutex to lock a specific kconfig object (i.e. project config).
> > This could be done by wrapping KConfig in a custom class that replicates
> > some of KConfig's API but would mean adjusting all code that uses it and
> > it would also mean loosing some things from the API (like fetching a
> > config group and writing to it transparently).
> 
> Well then, I guess that the way to solve that for the moment is to move
> these KConfig accesses to the project initialization.
> That might speed up a little the parsing too.

I don't see how that would work as you need to access kconfig to find
out the builddir when the C++ support asks for the include dirs. You
cannot do that once and store it as the user may change the builddir any
time during the runtime of kdevelop.

Andreas

-- 
You are dishonest, but never to the point of hurting a friend.