Thread-safety issue in cmake support ?

[Andreas Pakulat]

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

Andreas

-- 
Things will be bright in P.M.  A cop will shine a light in your face.