Thread-safety issue in cmake support ?

[Andreas Pakulat]

On 09.06.10 08:23:53, Christoph Cullmann wrote:
> On Monday 07 June 2010 19:40:37 Milian Wolff wrote:
> > > 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.
> The right solution (TM) is simple:
> You must first pack all stuff needed for your thread into a local copy, then start it working only on that copy of the data and only do feedback via a well defined interface, for example some queued signals at the very end.
> For the KConfig case, that means collecting the needed config values once before the parsing thread does its work. It makes no sense to allow changing config while it is running anyway, then
> you can abort and restart the parsing in any case.

This already doesn't work, as its being done in a background thread
(with the current framework) and hence any time the same configuration
object may be accessed from the foreground thread.

Andreas

-- 
Love is in the offing.  Be affectionate to one who adores you.