Thread-safety issue in cmake support ?

[Esben Mose Hansen]

On Wednesday 09 June 2010 08:23:53 Christoph Cullmann wrote:
> 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.
> For the kate part case that means, getting text and revision number, doing
> all parsing on the copy and create dumb ranges in the thread, after done,
> creating + translating the moving ranges in the main thread.

Thank you for doing my todo-list for me :) This is exactly what we need to 
migrate towards. That is, we need a rule that once a thread is spawned, it is 
only allowed to access its own data. Yes, it will be a long time before that 
is totally true, but every time a thread job does this KDevelop will be a 
little more stable.

Surely, working towards this is not impossible?

-- 
kind regards, Esben
Ange Optimization Aps
http://ange.dk