Thread-safety issue in cmake support ?

[Andreas Pakulat]

On 09.06.10 13:06:50, Esben Mose Hansen wrote:
> 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?

The question is not so much what is possible and what is not, but what is
realistic to do. I don't know the job-creation enough to know wether its
possible to implement such a change without rewriting half (or more) of the
codebase, but such a huge rewrite is probably not going to happen (in
particular because there's currently nobody with time+knowledge to work on
language support at all)

Andreas

-- 
Don't get to bragging.