Thread-safety issue in cmake support ?

[Andreas Pakulat]

On 07.06.10 14:53:52, Sandro Andrade wrote:
> On Mon, Jun 7, 2010 at 2: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...
> 
> Is there really a need for a single global lock ? Couldn't we define
> specific locks for groups of features and somehow detect which ones
> should be locked according with the touched pieces ?

Well, we could certainly have a separate mutex for kconfig access, but
that means wrapping kconfig into a custom API loosing some of the things
possible with kconfig directly (unless we invest huge amount of work to
replicate the complete API, basically rewriting the API in a thread-safe
manner).

Andreas

-- 
Be free and open and breezy!  Enjoy!  Things won't get any better so
get used to it.