Threadsafe project model
zwabel at googlemail.com
Thu Jul 15 22:30:20 UTC 2010
Locking within every single sub-function of the project-model still
wouldn't solve consistency-problems, like for example:
thread A: item.setParent(someting)
thread B: item.setParent(someThingElse)
thread A: ASSERT(item.parent() == someting) <- BANG
Or even worse, one thread could delete the imem.
If you simply define that the project-model belongs to the foreground,
you can use the foreground lock. In order to have an advantage, the
parsers need to be designed to only lock it for short times, but
during those times, the state is guaranteed to be as expected, without
strange interactions with other threads.
Do complicated and slow stuff, build duchain, resolve variables, regexes, etc.
QString targetName = blabla;
QStringList fileList = blub;
-> Allocate/update project items for this target only, but do nothing
More information about the KDevelop-devel