Thread-safety issue in cmake support ?

[Andreas Pakulat]

On 07.06.10 12:40:20, Sandro Andrade wrote:
> On Mon, Jun 7, 2010 at 12:20 PM, Milian Wolff <mail at milianw.de> wrote:
> > Sandro Andrade, 07.06.2010:
> >> Hi there,
> >>
> >> I sent this issue some time ago regarding multiple access to KConfig
> >> and I've been told to ask kde-core-devel guys
> >> about KConfig thread safety. However, KConfig is neither thread-safe
> >> nor even reentrant:
> >>
> >> http://lists.zerezo.com/kde-devel/msg12619.html
> >> http://lists.kde.org/?l=kde-devel&m=118037451920733&w=2
> >>
> >> So I should take care of this. The problem raises from calling
> >> "buildSystemManager->includeDirectories(project_item)" from multiples
> >> threads. I need to obtain project's include directories but probably
> >> the concurrent execution of background parser is causing such a crash
> >> (see following backtrace).
> >
> > Either put a mutex into your plugin or directly into cmake - dunno. You should
> > investigate where the function is currently used (isn't that used somewhere in
> > the background parser? meaning from multiple threads?)
> 
> I'm afraid putting a mutex (actually it already exists) in plugin does not
> solves the problem since it cames from somewhere out of plugin scope.
> 
> I suspect any concurrent execution of buildsystem's methods which access
> KConfig (more specifically CMakeUtils methods) would produce such error
> (in this case, currentInstallDir - executed from plugin - against
> currentBuildDir - from some still unknown place).
> 
> 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.

No it won't. If the problem really is that access a KSharedConfig::Ptr from
multiple threads is not safe then the only solution is to drop
multi-threading. And by that I don't mean remove it everywhere, but I mean
that introducing the proposed "GUI lock" will make kdevelop almost
single-threaded. There are tons of code all over the place that access the
project config any time.

Andreas

-- 
A gift of a flower will soon be made to you.