Thread-safety issue in cmake support ?

[Andreas Pakulat]

On 07.06.10 19:40:37, Milian Wolff 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

How about we check what other ide's are doing (Qt Creator, Netbeans also
has strong c++ support, maybe Eclipse CDT) and check wether its feasible
to go the same route?

> :-) Until then, it's probably the only thing we can do.

Have fun :)

> There are sadly too many tools out there which we must use that do not work in 
> a multi threaded environment...

At least for the cmake-plugin case what could also be done is having the
parser use a blocking-queued-connection to fetch the includes. That
might be the "quickest" fix and would allow to check how bad the impact
of such locking is to the background threads at least.

Andreas

-- 
Today is what happened to yesterday.