Thread-safety issue in cmake support ?
sandro.andrade at gmail.com
Mon Jun 7 15:40:20 UTC 2010
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:
>> 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.
> If so, we'd need to put it into the CMake plugin directly.
> anyhow: it's interesting to know that this is not threadsafe, afaik there are
> a few places in KDevelop assuming that it _is_ threadsafe ;-) Oh boy, the joy
> of multithreading :]
> Milian Wolff
> mail at milianw.de
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
More information about the KDevelop-devel